io.github.g-digital-by-Garrigues/ead-enterprise-suite
NPM · @G-DIGITAL/MCP-EAD-ENTERPRISE-SUITE · SCANNED SEP 21
MCP server for EAD Enterprise Suite - signatures, evidence, notifications, dossiers via AI agents.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 37 of 111 dependencies flagged as unhealthy (1 deprecated). View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Build provenance is cryptographically sound, but it attests a different repository to the one declared in the registry. Most often the declared URL is simply stale. View diagnostics → Unverified
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 12 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability65
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 13445 tokens (~156/item across 86 items; 86 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management95
- Stability check failed: the tool surface changed between 1.6.1 and 2.0.0: 0 tool removals, 2 breaking changes, 34 additions. See how to fix → Fail
Tool Coverage70
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 11% of tool parameters carry a description.Partial
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 13 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 86 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the io.github.g-digital-by-Garrigues/ead-enterprise-suite MCP server?
io.github.g-digital-by-Garrigues/ead-enterprise-suite runs locally as an npm package, launched with npx -y @g-digital/mcp-ead-enterprise-suite. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · @g-digital/mcp-ead-enterprise-suite
claude mcp add g-digital-by-garrigues-ead-enterprise-suite -- npx -y @g-digital/mcp-ead-enterprise-suite
{
"mcpServers": {
"g-digital-by-garrigues-ead-enterprise-suite": {
"command": "npx",
"args": [
"-y",
"@g-digital/mcp-ead-enterprise-suite"
]
}
}
} {
"servers": {
"g-digital-by-garrigues-ead-enterprise-suite": {
"command": "npx",
"args": [
"-y",
"@g-digital/mcp-ead-enterprise-suite"
]
}
}
} codex mcp add g-digital-by-garrigues-ead-enterprise-suite -- npx -y @g-digital/mcp-ead-enterprise-suite
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"g-digital-by-garrigues-ead-enterprise-suite": {
"type": "local",
"command": [
"npx",
"-y",
"@g-digital/mcp-ead-enterprise-suite"
],
"enabled": true
}
}
} openclaw mcp add g-digital-by-garrigues-ead-enterprise-suite --command npx --arg -y --arg @g-digital/mcp-ead-enterprise-suite
mcp_servers:
g-digital-by-garrigues-ead-enterprise-suite:
command: "npx"
args: ["-y", "@g-digital/mcp-ead-enterprise-suite"] {
"McpServers": {
"g-digital-by-garrigues-ead-enterprise-suite": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"@g-digital/mcp-ead-enterprise-suite"
]
}
}
} assistant mcp add g-digital-by-garrigues-ead-enterprise-suite -t stdio -c npx -a -y @g-digital/mcp-ead-enterprise-suite
{
"mcpServers": {
"g-digital-by-garrigues-ead-enterprise-suite": {
"command": "npx",
"args": [
"-y",
"@g-digital/mcp-ead-enterprise-suite"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 21 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 91 to 95.
- 18 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 81 to 85.
- 16 Sept 26 −2
No change was recorded against any check on this day. Stability & Change Management went from 98 to 78.
- 14 Sept 26 +1
- Package version: 1.6.1 → 2.0.0 functional
- 13 Sept 26 0
- Security disclosure: unverified → fail ▼ functional
- 12 Sept 26 0
- Security disclosure: fail → unverified ▼ functional
- 11 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 81 to 85.
- 9 Sept 26 +13
- Malware scan: unverified → pass ▲ security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Analysed npm/@g-digital/mcp-ead-enterprise-suite@2.0.0
Provenance Repository mismatch
The attestation is cryptographically sound but binds a different repository to the one the registry declares. Most often the declared URL is simply stale.
| Result | Repository mismatch |
|---|---|
| Ecosystem | npm |
| Reason | Repository mismatch |
| Discovered via | Registry attestation endpoint |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/g-digital-by-Garrigues/MCP_Market_Distribution/.github/workflows/publish.yml@refs/heads/main |
| Rekor log index | 2755465691 |
| Predicate type | https://slsa.dev/provenance/v1 |
| Subject digest | sha512:ee68289876ebbdc5d839402a4f48b5eb1eabc2746b84e2a5bcc625eaaa859ed155c9b131f87bdadfd46af094931327a95c71f70c24b6e62ba7ad57cd6 |
Background: How many MCP packages publish verified provenance →
Dependencies 111 packages
| Packages resolved | 111 |
|---|---|
| Deprecated | 1 |
| Stale | 36 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
notification_receiver_list ~176
Lists a notification's recipients with their individual delivery state. Returns per recipient: id, firstName, lastName, email, phonePrefix/phoneNumber, status (INVALID, READY_TO_SEND, SENT, READ, ANSWERED, ERROR), statusUpdatedAt, `answer` once they respond, emailBounced, and validationError (TAKEN, IS_DEFINED, IS_INVALID) for a rejected address. Worth calling before notification_request_send to see whether any address came back INVALID, and after sending to see who read or answered. Also the way to recover a receiverId for notification_certificate_get. Paginated; filterable by id.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| filter | object | – | – |
| notificationRequestId | string | yes | – |
| order | object | – | – |
| page | object | – | – |
No output schema declared.
No examples provided.
notification_receiver_update ~181
Corrects a recipient's details: firstName, lastName, email, phonePrefix, phoneNumber. Requires receiverId, notificationRequestId and caseFileId. Use this to fix a mistyped address rather than deleting and re-adding, which would lose the receiverId. phonePrefix must include the + (for example +34). A phone number is required if the recipient is to receive the RCS/SMS link (sendSmsUrl), the WhatsApp link (sendWaUrl), or an OTP challenge (otpRequired).
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| string | – | – | |
| firstName | string | – | – |
| lastName | string | – | – |
| notificationRequestId | string | yes | – |
| phoneNumber | string | – | – |
| phonePrefix | string | – | – |
| receiverId | string | yes | – |
No output schema declared.
No examples provided.
notification_request_case_file_move ~89
Moves a notification to a different case file. Note the two caseFileId values: the one in the path is where the notification is NOW, and the one in the body is the destination. Notifications are grouped by case file, and this is the only way to change that grouping without duplicating.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| notificationRequestId | string | yes | – |
No output schema declared.
No examples provided.
notification_request_create ~239
Creates a certified notification request. Requires: case_file_create → caseFileId. Generate a UUID v4 for `id`. Set language to en_GB or es_ES. Returns notificationRequestId. Add at least one receiver with notification_receiver_add before sending. IMPORTANT: The `content` field must be valid HTML — plain text without HTML tags will not render on the recipient landing page. Only the following HTML formats are supported: paragraphs (<p>), bold (<strong>), italic (<em>), unordered lists (<ul><li>), ordered lists (<ol><li>). Do not use other HTML tags or CSS. Avoid special typographic characters (em dashes, smart quotes) in `subject`; use standard ASCII equivalents (hyphen, straight quotes) instead.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| content | string | yes | – |
| id | string | yes | – |
| language | string | yes | – |
| otpByDefault | boolean | – | – |
| sendSmsUrlByDefault | boolean | – | – |
| sendWaUrlByDefault | boolean | – | – |
| subject | string | yes | – |
| type | string | – | – |
No output schema declared.
No examples provided.
notification_request_delete ~90
Deletes a notification. Requires notificationRequestId and caseFileId. There is no undo. TESTED: once the notification has been sent the API rejects this with 403 Forbidden — a sent notification is delivery evidence and cannot be removed. If you only want it filed elsewhere, use notification_request_case_file_move instead.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| notificationRequestId | string | yes | – |
No output schema declared.
No examples provided.
notification_request_duplicate ~220
Creates a new DRAFT notification from an existing one, copying its content, its recipients and its attachments. Works whatever state the original is in, so this is how you resend to the same people or reuse a sent notification as a template. Generate a UUID v4 for `id` and supply a new `subject`; pass `caseFileId` in the body to place the copy in a different case file, or omit it to keep it alongside the original. THE COPY IS BUILT ASYNCHRONOUSLY: it starts in CREATING with zero recipients and zero documents, and fills in afterwards, so reading it immediately shows an empty notification that is not empty. Poll notification_request_status until the status is DRAFT before inspecting or sending it. Because recipients ARE copied, review them with notification_receiver_list before calling notification_request_send — otherwise you will send to the original list again.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | – | – |
| id | string | yes | – |
| notificationRequestId | string | yes | – |
| subject | string | yes | – |
No output schema declared.
No examples provided.
notification_request_list ~209
Lists the certified notifications visible to a user. Requires userId (from session_login, session_info or profile_get) — this listing is user-scoped, not case-file-scoped, so it spans every case file unless you filter. Use this to recover a notificationRequestId you no longer have; it is the only way to find one. Returns per notification: id, code, subject, status, type, sentAt, receiverStats and the owning caseFile. Filter by `status` or `statuses` (CREATING, DRAFT, IN_PROCESS, SENT, PARTIALLY_READ, FULLY_READ, PARTIALLY_ANSWERED, FULLY_ANSWERED), by `caseFileIds`, by `search` over the subject, or by `receiversSearch` to find the notification sent to a given recipient. Paginated.
| Name | Type | Req | Description |
|---|---|---|---|
| filter | object | – | – |
| order | object | – | – |
| page | object | – | – |
| userId | string | yes | – |
No output schema declared.
No examples provided.
notification_request_send ~59
Trigger delivery of a certified notification to all added recipients. Returns immediately — delivery is async. Poll notification_request_status until status is DELIVERED before retrieving certificates.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| notificationRequestId | string | yes | – |
No output schema declared.
No examples provided.
notification_request_status ~111
Checks the delivery status of a certified notification. Requires: notificationRequestId, caseFileId. Returns status (CREATING|DRAFT|IN_PROCESS|SENT|PARTIALLY_READ|FULLY_READ|PARTIALLY_ANSWERED|FULLY_ANSWERED). Poll until status is SENT or beyond. Do not call notification_certificate_get while status is CREATING, DRAFT, or IN_PROCESS.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| notificationRequestId | string | yes | – |
No output schema declared.
No examples provided.
notification_request_update ~207
Edits a notification that has not been sent: subject, content, type and language. Requires notificationRequestId and caseFileId. `content` must be valid HTML — plain text is accepted by the API but does NOT render on the recipient landing page. Supported tags only: <p>, <strong>, <em>, <ul><li>, <ol><li>; no other tags and no CSS. Keep `subject` to plain ASCII (no em dashes, no smart quotes), 100 characters maximum. TESTED: once the notification has been sent the API rejects this with 403 Forbidden, so editing only works before the send. To change which case file it belongs to use notification_request_case_file_move — this tool does not move it.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| content | string | – | – |
| language | string | – | – |
| notificationRequestId | string | yes | – |
| subject | string | – | – |
| type | string | – | – |
No output schema declared.
No examples provided.
notification_send ~694
Sends a certified notification to one or more recipients in a single call: creates the notification request, adds every recipient, and sends it. Generates every UUID itself — do not pass any id. Requires case_file_create → caseFileId. `content` MUST be HTML: plain text is accepted by the API and reports SENT but does not render on the recipient's landing page. Supported tags only: <p>, <strong>, <em>, <ul><li>, <ol><li> — no other tags, no CSS. Keep `subject` to plain ASCII, 100 characters maximum. Delivery is always by email; per recipient you can additionally set sendWaUrl (WhatsApp), sendSmsUrl (RCS or SMS depending on the handset) and otpRequired (one-time code), each of which needs phonePrefix with the + and phoneNumber. The maximum number of recipients is a per-subscription setting, not a fixed limit, so none is enforced here — the API rejects an oversized batch. This tool does NOT attach files; use notification_send_with_attachments for that, because attachments must be registered before recipients are added. PARTIAL SUCCESS IS REPORTED, NOT THROWN: if the request was created but a recipient or the send failed, the result still carries notificationRequestId together with recipientsAdded, recipientsFailed and sent:false, so you can finish with notification_receiver_add and notification_request_send instead of abandoning a draft. An INVALID recipient blocks the send, so this tool checks for one before sending and reports invalidRecipients rather than attempting a send that cannot succeed. If the initial create fails the tool raises an error instead: common causes are a caseFileId that does not exist, a subject over 100 characters, and an exhausted contracted notification plan, which no retry will fix. If that error is a timeout rather than a rejection, check notification_request_list before retrying — the request may have been created anyway. Poll notification_request_status for delivery progress, then notification_certificate_get per recipient.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | UUID of the case file the notification belongs to |
| content | string | yes | Body of the notification as HTML. Supported tags only: <p>, <strong>, <em>, <ul><li>, <ol><li>. No other tags and no CSS. Plain text is accepted by the API but does NOT render for the recipient. |
| language | string | yes | Language of the notification and its landing page |
| otpByDefault | boolean | – | Require a one-time code for every recipient that does not state its own otpRequired |
| recipients | array | yes | One or more recipients. The maximum is a per-subscription setting that varies by tenant and platform, so no limit is enforced here — if the tenant's cap is exceeded the API says so. |
| sendSmsUrlByDefault | boolean | – | Send the RCS/SMS link to every recipient that does not state its own sendSmsUrl |
| sendWaUrlByDefault | boolean | – | Send the WhatsApp link to every recipient that does not state its own sendWaUrl |
| subject | string | yes | Subject line, 100 characters maximum. Use plain ASCII — avoid em dashes and smart quotes. |
| type | string | – | What the recipient can do: NO_RESPONSE = read only; ACCEPTED_OR_NOT = accept or reject; RECEIVED_AGREE = acknowledge receipt and agree or disagree |
No output schema declared.
No examples provided.
notification_send_with_attachments ~847
Sends a certified notification WITH one or more attached documents to one or more recipients, in a single call. Use notification_send instead when there are no attachments. This tool exists separately because attachments impose an ordering rule the API enforces and does not forgive: documents must be registered and fully uploaded BEFORE any recipient is added, and every document must reach READY_TO_SEND before the notification is sent — otherwise the send fails with 409/404 NOTIFICATION_NOT_FOUND. The tool performs that whole sequence for you: create → register and upload each document → wait for READY_TO_SEND → add recipients → send. Each attachment takes a local file path, base64 content, an HTTPS URL, or an n8n binary reference; the hash and the upload are handled internally. Generates every UUID itself — do not pass any id. Requires case_file_create → caseFileId. `content` MUST be HTML: plain text is accepted by the API and reports SENT but does not render on the recipient's landing page. Supported tags only: <p>, <strong>, <em>, <ul><li>, <ol><li>. Keep `subject` to plain ASCII, 100 characters maximum. Delivery is always by email; per recipient you can additionally set sendWaUrl (WhatsApp), sendSmsUrl (RCS or SMS depending on the handset) and otpRequired (one-time code), each of which needs phonePrefix with the + and phoneNumber. The maximum number of attachments and of recipients are per-subscription settings, not fixed limits, so neither is enforced here. IF AN ATTACHMENT FAILS THE RUN STOPS BEFORE RECIPIENTS ARE ADDED, on purpose: once recipients exist the API will not accept further documents, so continuing would produce a notification that can never carry the missing file. The result reports the draft's notificationRequestId so you can retry or delete it. An INVALID recipient blocks the send, so the tool checks for one before sending and reports invalidRecipients instead of attempting a doomed send. If the initial create fails the tool raises an error ins…
| Name | Type | Req | Description |
|---|---|---|---|
| attachments | array | yes | One or more documents to attach. Each takes a local path, base64 content, an HTTPS URL or an n8n binary reference. The maximum is a per-subscription setting that varies by tenant and platform, so no… |
| caseFileId | string | yes | UUID of the case file the notification belongs to |
| content | string | yes | Body of the notification as HTML. Supported tags only: <p>, <strong>, <em>, <ul><li>, <ol><li>. No other tags and no CSS. Plain text is accepted by the API but does NOT render for the recipient. |
| language | string | yes | Language of the notification and its landing page |
| otpByDefault | boolean | – | Require a one-time code for every recipient that does not state its own otpRequired |
| recipients | array | yes | One or more recipients. The maximum is a per-subscription setting that varies by tenant and platform, so no limit is enforced here — if the tenant's cap is exceeded the API says so. |
| sendSmsUrlByDefault | boolean | – | Send the RCS/SMS link to every recipient that does not state its own sendSmsUrl |
| sendWaUrlByDefault | boolean | – | Send the WhatsApp link to every recipient that does not state its own sendWaUrl |
| subject | string | yes | Subject line, 100 characters maximum. Use plain ASCII — avoid em dashes and smart quotes. |
| type | string | – | What the recipient can do: NO_RESPONSE = read only; ACCEPTED_OR_NOT = accept or reject; RECEIVED_AGREE = acknowledge receipt and agree or disagree |
No output schema declared.
No examples provided.
profile_get ~228
Returns the authenticated user's own profile. It identifies the caller from the session token alone — no email or any other input needed — so it works on every deployment, including a per-request Bearer one. Its `id` field IS your userId (UUID): the value required by case_file_list and every /users/{userId}/... operation. Prefer this over session_info when you need the userId: it is the canonical source. Also returns companyId (needed to subscribe to the notifications SSE stream) and defaultCaseFileId. Also returns `permit`, a set of booleans — { evidences, idVerifications, notifications, chats, signatures } — that says which tool families this account may use at all: a false entry means every tool in that family returns 403 regardless of inputs, and no retry or different argument will help. Read it before calling into a family for the first time; on the integration deployment checked on 2026-09-07, permit.idVerifications was false and every identity tool returned 403 NoIdVerificationsPermit. No parameters.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
session_info ~170
Returns the authenticated user's session info. `type` is how this MCP session authenticated — always 'UserKey', the server's only auth flow. `accountLoginType` is a different fact: how the underlying EAD Enterprise Suite account itself signs in ('Password' or 'OpenId'), reported from GET /profile, null if the API omits it. Use this to retrieve the userId (UUID) required by case_file_list and other user-scoped operations, or to verify who is authenticated. profile_get is the canonical way to obtain the userId and returns more of the profile. Prerequisites: a valid session (call session_login first if needed). Example: session_info() → { userId: '...uuid...', type: 'UserKey', accountLoginType: 'Password' }
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
session_login ~85
Force the EAD Enterprise Suite MCP server to re-authenticate. Takes no parameters and accepts no credentials: the server re-exchanges the user key it was configured with (MCP_AUTH_USER_KEY) for a fresh session token, and this tool reports the resulting userId and expiry. The server manages authentication automatically — call this only to force a re-login or after a 401.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
signature_certificate_get ~93
Retrieves the signed document certificate PDF. Requires: activate_signature_request (document fully SIGNED), signature_request_add_document → documentId, signature_request_create → requestId, case_file_create → caseFileId. Returns documentUrl (signed PDF certificate). ASYNC: poll until documentUrl is available.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| documentId | string | yes | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_coordinate_set ~152
Sets the visual position of the signature field on a PDF document page. Required for PDF documents before activation, for both INTERPOSITION and ADVANCED signatures. Requires: signature_participant_create → signatoryId, signature_request_add_document → documentId, signature_request_create → requestId, case_file_create → caseFileId. Provide coordinates as array of {page (1-based), x (points from left), y (points from bottom)}. Set coordinates after the document has been uploaded and before activate_signature_request.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| coordinates | array | yes | – |
| documentId | string | yes | – |
| requestId | string | yes | – |
| signatoryId | string | yes | – |
No output schema declared.
No examples provided.
signature_document_list ~248
Lists the documents of a signature request with a document-level status and per-document statistics. Requires: signature_request_create → requestId, case_file_create → caseFileId. Items are { id, requestId, groupId, status, title, fileName, fileSize, convertToPdf, participantStats, signatoryStatusStats, signatoryCoordinatesStats } — for example status PARTIALLY_SIGNED with signatoryStatusStats { pending: 0, readyToSign: 1, signed: 1, rejected: 0 } and signatoryCoordinatesStats { defined: 2, missing: 0 } (live-read on INT 2026-09-07). signatoryCoordinatesStats.missing === 0 is the direct check that every required signatory has coordinates before activate_signature_request. Whether this status also reports upload processing for a freshly added document is NOT verified — keep using signature_request_get for that. For the signatories of one document use signature_document_signatory_list.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| filter | object | – | – |
| order | object | – | – |
| page | object | – | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_document_observer_list ~140
Lists the OBSERVERS of one document in a signature request — participants created with role OBSERVER, who receive a copy but never sign. Requires: signature_request_add_document → documentId, signature_request_create → requestId, case_file_create → caseFileId. Items carry only { id, email, firstName, lastName }: there is deliberately no status field, because an observer has nothing to complete. For the signers of the same document use signature_document_signatory_list.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| documentId | string | yes | – |
| page | object | – | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_document_signatory_list ~189
Lists the SIGNATORIES of one document in a signature request, with each signatory's status on that document. Requires: signature_request_add_document → documentId, signature_request_create → requestId, case_file_create → caseFileId. Items are { id, groupId, email, firstName, lastName, status, coordinates, uniqueValidator, phonePrefix, phoneNumber, participantStats } and status is PENDING, READY_TO_SIGN, VALIDATING, SIGNED or REJECTED. Each `id` is a signatoryId. To check whether the DOCUMENT itself reached READY_TO_SIGN before activate_signature_request, use signature_request_get; after activation poll here until every signatory is SIGNED before signature_certificate_get.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| documentId | string | yes | – |
| page | object | – | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_group_create ~260
Creates a signing order group for a CONFIGURABLE signature request. Types: 'Document' (groups documents into signing rounds — use its id as groupId in signature_request_add_document), 'Signatory' (groups signatories into signing rounds — use its id as groupId in signature_participant_create), 'DocumentSignatory' (links a specific document to a signing round, requires documentId). IMPORTANT — avoid empty groups: when a CONFIGURABLE request is created, the API automatically pre-creates one Document group and one Signatory group both at index:1. Always use these pre-existing index:1 groups for your first document and first signatory (retrieve their IDs with signature_group_list immediately after creating the request). Only call signature_group_create for the ADDITIONAL groups (index:2, 3…). Add participants with linkToAllDocuments:true so DocumentSignatory groups are auto-generated at the correct index. Adding participants without linkToAllDocuments leaves them unlinked to documents and signature_coordinate_set will fail with 'Signatory not found'.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| documentId | string | – | – |
| id | string | yes | – |
| requestId | string | yes | – |
| type | string | yes | – |
No output schema declared.
No examples provided.
signature_group_list ~105
Lists all signing order groups of a CONFIGURABLE signature request. Returns id, type (Document/Signatory/DocumentSignatory), index, and documentId for each group. Call immediately after signature_request_create to retrieve the pre-created index:1 group IDs before adding documents or participants.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| filter | object | – | – |
| order | object | – | – |
| page | object | – | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_participant_add_bulk ~139
Adds many participants to a DRAFT signature request in one call instead of one signature_participant_create per person. Requires: signature_request_create → requestId, case_file_create → caseFileId, and a `participants` array whose entries take the same fields as signature_participant_create, including the `id` and `role` you generate for each. Mixed roles in one call are allowed. Returns HTTP 201 with NO body, so keep the ids you minted and re-read the result with signature_participant_list.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| participants | array | yes | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_participant_create ~346
Adds one participant to a DRAFT signature request. This is the ONLY participant create endpoint: `role` selects SIGNATORY (must sign), OBSERVER (receives a read-only copy) or VALIDATOR (must approve before its signatory can sign). Requires: signature_request_create → requestId, case_file_create → caseFileId, plus role, firstName, lastName and email. YOU generate `id` (UUID v4) and the call returns HTTP 201 with NO body, so nothing is handed back — the id you generated IS the participantId, and it is the signatoryId if you passed role SIGNATORY or the validatorId if you passed role VALIDATOR. Keep it. For ADVANCED signatures phonePrefix and phoneNumber are mandatory because the signer receives the OTP there, and WhatsApp delivery is NOT supported for ADVANCED; for INTERPOSITION phone is optional and WhatsApp is available when the platform is configured for it. Add at least one SIGNATORY before activating. For role VALIDATOR do NOT include groupId or linkToAllDocuments — link it afterwards with assign_validator_to_signatory. Use signature_participant_add_bulk to add many at once, and signature_participant_list to re-read what exists.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| string | yes | – | |
| firstName | string | yes | – |
| groupId | string | – | – |
| id | string | yes | – |
| lastName | string | yes | – |
| linkToAllDocuments | boolean | – | – |
| phoneNumber | string | – | – |
| phonePrefix | string | – | – |
| requestId | string | yes | – |
| role | string | yes | – |
No output schema declared.
No examples provided.
signature_participant_delete ~127
Removes one participant from a signature request. Requires: signature_participant_create → participantId, signature_request_create → requestId, case_file_create → caseFileId. Use it to drop someone added by mistake, or to change a role (delete, then create again with the new role, since role is not updatable). Returns no body; confirm with signature_participant_list. To drop every invalid participant at once use signature_participant_invalid_purge instead.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| participantId | string | yes | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_participant_invalid_purge ~123
Removes every participant of a signature request that the platform has marked invalid, in one call. Requires: signature_request_create → requestId, case_file_create → caseFileId. signature_participant_list identifies them via `valid: false` and `validationError` — typically an undeliverable email or a malformed phone number. Returns no body; confirm with signature_participant_list. Prefer signature_participant_update when the detail can be repaired rather than the person dropped.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_participant_list ~190
Lists every participant of a signature request with the role each was created under — SIGNATORY, OBSERVER or VALIDATOR — plus contact details and validity. Requires: signature_request_create → requestId, case_file_create → caseFileId. Items are { id, requestId, groupId, role, firstName, lastName, email, phonePrefix, phoneNumber, createdAt, editable, emailBounced, valid, validationError, participantStats, documentStats }. This is the tool that resolves ids: an item's `id` is the participantId, and it is also the signatoryId when role is SIGNATORY and the validatorId when role is VALIDATOR. Supports filter, order and page.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| filter | object | – | – |
| order | object | – | – |
| page | object | – | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_participant_update ~200
Corrects a participant's details before the signature request is activated. Requires: signature_participant_create → participantId, signature_request_create → requestId, case_file_create → caseFileId. Any of groupId, firstName, lastName, email, phonePrefix and phoneNumber may be sent. The role CANNOT be changed, so to turn a signatory into an observer, delete it and create it again. Use this to repair a bounced or mistyped email — signature_participant_list reports emailBounced and validationError. Returns no body; confirm with signature_participant_list.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| string | – | – | |
| firstName | string | – | – |
| groupId | string | – | – |
| lastName | string | – | – |
| participantId | string | yes | – |
| phoneNumber | string | – | – |
| phonePrefix | string | – | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_request_add_document ~340
Adds a document to a DRAFT signature request. Requires: signature_request_create → requestId, case_file_create → caseFileId. Provide a string `id` for the document. Compute SHA-256 hex hash of the PDF before calling. Optional: pass `fileUrl` (a publicly accessible URL) to have the tool download and upload the file to S3 automatically — no separate PUT needed. If fileUrl is omitted, returns url (presigned S3 upload URL) for manual PUT. Cannot add documents after activate_signature_request is called. For CONFIGURABLE sequence: `groupId` must reference a Document type group (not Signatory or DocumentSignatory) — passing a wrong group type returns 'Signature group not found'.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | UUID of the case file |
| convertToPdf | boolean | – | Convert non-PDF to PDF before processing |
| fileName | string | yes | File name including extension (e.g. contract.pdf) |
| fileSize | number | – | File size in bytes (optional) |
| fileUrl | string | – | Optional public URL to download and auto-upload the PDF to S3. Eliminates the manual PUT step. |
| groupId | string | – | For CONFIGURABLE sequence: ID of a Document type group |
| hash | string | yes | SHA-256 hex digest of the PDF content (64 hex chars) |
| id | string | yes | UUID for the document — becomes documentId for coordinate_set and certificate_get |
| requestId | string | yes | UUID of the signature request (DRAFT) |
| title | string | yes | Document title shown to signatories |
No output schema declared.
No examples provided.
signature_request_cancel ~59
Cancels an active signature request. Requires: activate_signature_request (ACTIVE status), requestId, caseFileId. Transitions to CANCELLED. Cannot be undone.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_request_create ~150
Creates a new signature request in DRAFT status. Requires: case_file_create → caseFileId. Generate a UUID v4 for `id`. Set deadline as ISO 8601 datetime (max ~30 days ahead). Returns requestId. Add documents with signature_request_add_document and participants with signature_participant_create before activating.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| closeCondition | string | – | – |
| dashboardUrl | string | – | – |
| deadline | string | yes | – |
| id | string | yes | – |
| language | string | yes | – |
| name | string | yes | – |
| objectiveId | string | – | – |
| sequence | string | – | – |
| signatureType | string | – | – |
No output schema declared.
No examples provided.
signature_request_get ~70
Retrieves full details of a signature request. Requires: signature_request_create → requestId, case_file_create → caseFileId. Returns status, documents, participants, deadline, and history. Use to check overall process state.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| requestId | string | yes | – |
No output schema declared.
No examples provided.
signature_signatory_progress_list ~221
Lists the documents assigned to ONE signatory of a signature request, with that signatory's progress on each. Requires: caseFileId, requestId and signatoryId. The signatoryId is the `id` of a participant whose role is SIGNATORY — read it from signature_participant_list or signature_document_signatory_list. Passing a participant id whose role is not SIGNATORY returns 404 'Signatory not found' — observed on INT 2026-09-07 with a VALIDATOR id; it is one id space, but the signatory-scoped endpoints accept only the ids of SIGNATORY participants. Returns { data, meta.totalElements } with items { id, fileName, fileSize, status }, where status is PENDING, READY_TO_SIGN, SIGNED or REJECTED.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| filter | object | – | – |
| order | object | – | – |
| page | object | – | – |
| requestId | string | yes | – |
| signatoryId | string | yes | – |
No output schema declared.
No examples provided.
signature_validator_list ~165
Lists the validators currently linked to ONE signatory of a signature request. Requires: signature_participant_create (signatory) → signatoryId, signature_request_create → requestId, case_file_create → caseFileId. Items carry { id, email, firstName, lastName }, where each `id` is a validatorId. Note the two-step model: creating a participant with role VALIDATOR does not attach it to anyone, so a validator can exist on the request and not appear here until assign_validator_to_signatory links it — an empty list means nothing is linked yet, not that no validator exists.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| page | object | – | – |
| requestId | string | yes | – |
| signatoryId | string | yes | – |
No output schema declared.
No examples provided.
signature_validator_unassign ~134
Unlinks one validator from one signatory, reversing assign_validator_to_signatory. Requires: signature_validator_list → validatorId, signature_participant_create (signatory) → signatoryId, signature_request_create → requestId, case_file_create → caseFileId. This removes the LINK only: the validator remains a participant of the request, so use signature_participant_delete to remove the person entirely. Returns no body; confirm with signature_validator_list.
| Name | Type | Req | Description |
|---|---|---|---|
| caseFileId | string | yes | – |
| requestId | string | yes | – |
| signatoryId | string | yes | – |
| validatorId | string | yes | – |
No output schema declared.
No examples provided.
use_case_list ~54
Lists available use cases for the account. Use cases define the allowed signature workflows and document types. Returns useCaseId values needed for signature_request_create.
| Name | Type | Req | Description |
|---|---|---|---|
| companyId | string | yes | – |
| page | object | – | – |
No output schema declared.
No examples provided.
What is the io.github.g-digital-by-Garrigues/ead-enterprise-suite MCP server?
io.github.g-digital-by-Garrigues/ead-enterprise-suite is an MCP server listed in the public MCP registry as io.github.g-digital-by-Garrigues/ead-enterprise-suite. MCP server for EAD Enterprise Suite - signatures, evidence, notifications, dossiers via AI agents. This page covers its npm package (@g-digital/mcp-ead-enterprise-suite).
Is the io.github.g-digital-by-Garrigues/ead-enterprise-suite MCP server safe to use?
io.github.g-digital-by-Garrigues/ead-enterprise-suite scores 79 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.g-digital-by-Garrigues/ead-enterprise-suite MCP server expose?
io.github.g-digital-by-Garrigues/ead-enterprise-suite exposes 86 tools: evidence_create, evidence_list, evidence_seal, evidence_get, evidence_group_create, and 81 more. Their descriptions and schemas cost roughly 13,445 tokens of context every time the server is loaded.
Is the io.github.g-digital-by-Garrigues/ead-enterprise-suite MCP server still maintained?
io.github.g-digital-by-Garrigues/ead-enterprise-suite is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the io.github.g-digital-by-Garrigues/ead-enterprise-suite MCP server under?
io.github.g-digital-by-Garrigues/ead-enterprise-suite declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.