PenlyDoc MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PENLY_URL | No | The PenlyDoc instance URL to use. | https://penlydoc.com |
| PENLY_API_KEY | Yes | Your PenlyDoc organisation's API key from Console → Developers. The server uses it to talk to the PenlyDoc REST API. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_organisationA | Shows which PenlyDoc organisation the API key belongs to, its default language and its sending limit. |
| list_templatesA | Lists the organisation's templates: id, name, the roles to fill (e.g. "tenant", "landlord"), the data keys to fill, and whether the template is ready to send. |
| send_from_templateA | Creates a document from a template: one person per role, values for its data keys. With send=true PenlyDoc immediately e-mails the people with delivery EMAIL; confirm the people and values with the user first. With send=false it creates a draft the user can review in the console. Use the same externalRef/idempotencyKey to safely retry. |
| send_documentA | Uploads local files (PDF, or PNG/JPEG photos of pages, joined in order) and creates a document for signature. Signature boxes come from {{sig:1}}-style tags in the PDF or from the fields argument (points, top-left origin). With send=true PenlyDoc e-mails the people right away; confirm with the user first. Without tags or fields, use send=false and let the user place the boxes in the console (the result has a link). |
| list_documentsA | Lists documents sent for signature, newest first, with who has signed. Filter by status or by your externalRef. |
| get_documentA | Full status of one document: each person, whether they opened, signed or declined (with the reason), and when. |
| get_historyA | The hash-chained history of a document: every step with time, who and IP address, and whether the chain is intact. |
| send_draftA | Sends a DRAFT document: PenlyDoc e-mails the first people to sign. Confirm with the user first. |
| send_reminderA | E-mails a reminder now to everyone whose turn it is on this document. Confirm with the user first. |
| cancel_documentA | Cancels (voids) a document that is still being signed. Signing links stop working and the people still to act are told by e-mail. This cannot be undone; confirm with the user first. |
| create_signing_linkA | Creates a one-hour signing link for a person with delivery EMBEDDED, to open in your own app or hand to that person. The link lets whoever has it sign as that person: share it only with them. |
| download_signed_pdfA | Saves the sealed, signed PDF (with the certificate of completion as last page) of a COMPLETED document to a local file. |
| verify_pdfA | Checks a local signed PDF: is the seal intact, when was it sealed, who signed. Works for any PDF; nothing is stored. No API key needed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools have clearly distinct resource/action targets, and the descriptions clarify the main overlapping area: creating documents from templates versus uploading local files. The send_* family (send_from_template, send_document, send_draft, send_reminder) is the only place where an agent might briefly pause, but each has a specific purpose.
All tool names use consistent snake_case and follow a predictable verb_noun pattern, such as get_organisation, list_documents, cancel_document, and verify_pdf. The minor variation in send_from_template is still readable and fits the same convention.
With 13 tools, the server stays within a well-scoped range for an e-signature document workflow. Each tool covers a meaningful step: organisation lookup, templates, sending, status tracking, reminders, cancellation, signing links, and PDF verification.
The surface covers the core document lifecycle from template/upload through sending, status checks, history, reminders, cancellation, signed PDF download, and verification. Minor gaps exist around template management beyond listing and document metadata updates, but the main workflow is well covered.