Doksi

Official22 toolsLive

by Publifye · Python

Professional PDFs for AI: letters, agreements, agendas, checklists — signatures by link or QR

pro.publifye/doksi — Model Context Protocol (MCP) Server

This MCP server (“pro.publifye/doksi”) provides professional PDF documents for AI use cases, covering letters, agreements, agendas, and checklists. The description indicates that signatures can be provided by link or QR.

🛠️ Key Features

Professional PDFs for AI
Document types: letters, agreements, agendas, checklists
Signatures supported via link or QR

🚀 Use Cases

Generating AI-ready PDF documents for letters
Producing PDFs for agreements
Creating agendas and checklists as PDF documents
Collecting signatures using link-based or QR-based methods

⚡ Developer Benefits

Clear document categories listed in the server description
Signature workflow options explicitly specified (link or QR)

⚠️ Limitations

No additional details are provided for tool count, topics, or technical integration specifics in the available source data

Topics

aibiblebrregclaudedictionaryepubgreekhebrewlexicographylexiconllmmcpmodel-context-protocolnorwaypublishingstrongslovdatamcp-servernorwegian-law

Declared in the repository manifest (services/doksi/tools.json). Not verified against a live endpoint.

kind_list

List the eight document kinds doksi makes, with what each one is for. Read this before doc_compose if you are unsure which kind fits: the kinds differ in LAYOUT, not in wording. An application, request, complaint or resignation is a purpose on letter_official (see purpose_list), not a separate kind. For a formal job, admission, grant or permit application, call doc_requirements(kind:letter_official, purpose:application). letter_personal is for private correspondence.

Parameters

No parameters.

Raw schema

{
  "type": "object"
}

purpose_list

List the curated purposes an official letter can have, with the EXTRA fields each one requires. A purpose supplies default subject, salutation and closing wording in Norwegian and English, and may demand fields the kind alone does not — a request needs a response-by date, a termination needs an effective date and a notice period. Applications use application: content.purpose.concerning.what must name the role, programme, grant or permission sought. Purposes are optional on official letters and forbidden on personal letters; do not invent purpose IDs.

Parameters

No parameters.

Raw schema

{
  "type": "object"
}

block_types

List the building blocks a document body is made of, and which kinds accept each one. The set is CLOSED: an unknown block type is refused naming what the kind does take, because a document that quietly dropped its table is worse than one that refused.

Parameters1

kind

string

optional

Restrict to the blocks this kind accepts

Raw schema

{
  "properties": {
    "kind": {
      "description": "Restrict to the blocks this kind accepts",
      "enum": [
        "letter_personal",
        "letter_official",
        "notice",
        "agreement",
        "covenant",
        "checklist",
        "meeting",
        "schedule"
      ],
      "type": "string"
    }
  },
  "type": "object"
}

doc_requirements

Return the exact field requirements for one kind, optionally composed with one purpose. Each field is required, optional or forbidden, and a forbidden field is refused by name — reference numbers on a personal letter, for instance. Includes a complete JSON Schema, nested field shapes and a valid document example. Meetings and schedules support qr_url and qr_placement (bottom_center default, top_right, hidden); supplied owner names are printed. Read this before composing. For an application letter pass kind:letter_official and purpose:application. Ask for missing required facts; never invent addresses, qualifications or reference numbers.

Parameters2

kind	string	required	Document kind
purpose	string	optional	Optional purpose id, for letter_official only

Raw schema

{
  "properties": {
    "kind": {
      "description": "Document kind",
      "enum": [
        "letter_personal",
        "letter_official",
        "notice",
        "agreement",
        "covenant",
        "checklist",
        "meeting",
        "schedule"
      ],
      "type": "string"
    },
    "purpose": {
      "description": "Optional purpose id, for letter_official only",
      "type": "string"
    }
  },
  "required": [
    "kind"
  ],
  "type": "object"
}

doc_validate

Check a document against its kind's requirements and report EVERY problem at once, never just the first — you cannot see the page, so one problem per call would be a dozen round trips. Each problem carries the exact JSON path to fix, why the field exists, and whether it is missing (you have not filled it in) or malformed (it is filled in wrongly). Does not render a PDF; customer API call limits still apply.

Parameters1

document

object

required

The whole document object, as doc_requirements describes it

Raw schema

{
  "properties": {
    "document": {
      "description": "The whole document object, as doc_requirements describes it",
      "type": "object"
    }
  },
  "required": [
    "document"
  ],
  "type": "object"
}

doc_compose

Compose a document and typeset it in ONE call: validate, render, and return the PDF. This is the tool to use when you have the content. Get a complete JSON example and schema from doc_requirements first. For formal application letters, including job applications, use kind letter_official with content.purpose.id application; doc_requirements(kind:letter_official, purpose:application) describes the required fields. This creates a PDF; it does not submit an application. On a validation failure nothing is rendered and you get the same problem list doc_validate returns, so a refusal is a result to act on rather than an error to retry.

Parameters3

document	object	required	The whole document object
include	array	optional	Which representations to return: pdf (base64 bytes), json (canonical document). Defaults to pdf. Use issue:true with include:[json] for a shareable PDF URL.
issue	boolean	optional	Also ISSUE the document: keep it and mint a capability link you can hand to somebody. Off by default — composing is cheap and repeatable, issuing keeps a copy.

Raw schema

{
  "properties": {
    "document": {
      "description": "The whole document object",
      "type": "object"
    },
    "include": {
      "description": "Which representations to return: pdf (base64 bytes), json (canonical document). Defaults to pdf. Use issue:true with include:[json] for a shareable PDF URL.",
      "items": {
        "type": "string"
      },
      "type": "array"
    },
    "issue": {
      "description": "Also ISSUE the document: keep it and mint a capability link you can hand to somebody. Off by default — composing is cheap and repeatable, issuing keeps a copy.",
      "type": "boolean"
    }
  },
  "required": [
    "document"
  ],
  "type": "object"
}

doc_get

Read the original structured document JSON retained when doc_issue or doc_compose(issue:true) issued a PDF. Use the returned document to inspect wording, block IDs, image references and fields, then edit and validate it before issuing a NEW document. This does not extract text from the PDF, re-render, or modify the issued document. Older documents may have source_available:false. Requires authenticated write access and the private document id, like document link management. Revoking a public PDF link does not erase this retained record.

Parameters1

string

required

The private document id returned at issuance; not its public PDF token or URL

Raw schema

{
  "properties": {
    "id": {
      "description": "The private document id returned at issuance; not its public PDF token or URL",
      "type": "string"
    }
  },
  "required": [
    "id"
  ],
  "type": "object"
}

doc_issue

Typeset a document, KEEP it, and return a permanent link that opens it — no login, no account, no expiry. This is the normal way to deliver a document: give the person the link. The link is the credential, so treat it like one: it is not indexed anywhere and it is not guessable, but anyone holding it can open the document. If it reaches the wrong person, doc_link_rotate replaces it and doc_link_revoke kills it — which is exactly what an emailed attachment can never do. The stored bytes never change afterwards. A template fix or a font change does not alter a document somebody already received.

Parameters2

document	object	required	The whole document object
filename	string	optional	What the person sees when saving, e.g. oppsigelse.pdf

Raw schema

{
  "properties": {
    "document": {
      "description": "The whole document object",
      "type": "object"
    },
    "filename": {
      "description": "What the person sees when saving, e.g. oppsigelse.pdf",
      "type": "string"
    }
  },
  "required": [
    "document"
  ],
  "type": "object"
}

doc_share

Typeset a document and hand back a TEMPORARY download link a person can open — no login, no account, and it expires. Use this when somebody needs the document itself rather than the bytes: paste the link into a chat or an email and they click it. The link is private and short-lived by design. It is not published anywhere, it never reaches the open web, and it can be killed early with doc_share_revoke. Validation runs first: an incomplete document produces the same problem list doc_validate returns and nothing is uploaded.

Parameters4

document	object	required	The whole document object
filename	string	optional	What the person sees when saving, e.g. oppsigelse.pdf
title	string	optional	What the document IS, in human words
ttl_seconds	integer	optional	How long the link works. Default 3600 (one hour), minimum 60, maximum 604800 (one week). The value actually granted is returned — it is clamped, and reporting what was asked for rather than what was allowed is how a person gets told the wrong expiry.

Raw schema

{
  "properties": {
    "document": {
      "description": "The whole document object",
      "type": "object"
    },
    "filename": {
      "description": "What the person sees when saving, e.g. oppsigelse.pdf",
      "type": "string"
    },
    "title": {
      "description": "What the document IS, in human words",
      "type": "string"
    },
    "ttl_seconds": {
      "description": "How long the link works. Default 3600 (one hour), minimum 60, maximum 604800 (one week). The value actually granted is returned — it is clamped, and reporting what was asked for rather than what was allowed is how a person gets told the wrong expiry.",
      "type": "integer"
    }
  },
  "required": [
    "document"
  ],
  "type": "object"
}

doc_share_revoke

Kill a temporary link now, before it expires. Use it the moment a document went to the wrong person: the link stops working immediately and the bytes are dropped. Revoking an already-dead link is not an error — it is the outcome you wanted.

Parameters1

file_id

string

required

The id returned by doc_share

Raw schema

{
  "properties": {
    "file_id": {
      "description": "The id returned by doc_share",
      "type": "string"
    }
  },
  "required": [
    "file_id"
  ],
  "type": "object"
}

doc_link_rotate

Replace a document's link with a new one. The old link stops working immediately, the document is untouched, and you get a fresh link to send. Use this when a link was forwarded further than intended.

Parameters1

string

required

The document id from doc_issue

Raw schema

{
  "properties": {
    "id": {
      "description": "The document id from doc_issue",
      "type": "string"
    }
  },
  "required": [
    "id"
  ],
  "type": "object"
}

doc_link_revoke

Kill a document's link with no replacement. Anyone opening it afterwards is told the link was withdrawn. The DOCUMENT IS KEPT — revoking decides who may fetch it, and is not a way to erase a record somebody may already hold a copy of.

Parameters1

string

required

The document id from doc_issue

Raw schema

{
  "properties": {
    "id": {
      "description": "The document id from doc_issue",
      "type": "string"
    }
  },
  "required": [
    "id"
  ],
  "type": "object"
}

doc_mail_to_me

Email an issued document to the address you are signed in as. The document is attached and the link is in the body. IT GOES ONLY TO YOU. doksi does not email documents to anyone else, and there is no argument that changes that: sending a person's correspondence onward would put our sending reputation behind somebody else's letter. To reach a recipient, send them the document's link yourself — from your own address, under your own name. Reports the document as QUEUED, never as delivered: pubmail accepts it for sending and reports failures separately, so 'sent' would be a claim this service cannot make.

Parameters1

string

required

The document id from doc_issue

Raw schema

{
  "properties": {
    "id": {
      "description": "The document id from doc_issue",
      "type": "string"
    }
  },
  "required": [
    "id"
  ],
  "type": "object"
}

signature_describe

Describe recipients and available named signature slots in a document. Signing is OPTIONAL: recipients are not automatically signers. Returns slot IDs, roles and placement without image data. Use doc_requirements for the full schema, then explicitly select slots for signature_request_create.

Parameters1

document

object

required

Complete Doksi document

Raw schema

{
  "properties": {
    "document": {
      "description": "Complete Doksi document",
      "type": "object"
    }
  },
  "required": [
    "document"
  ],
  "type": "object"
}

signature_request_create

Freeze a complete document revision and create optional signing requests for selected named signature slots. Returns a private overview_url with every selected signer, individual copy links and QRs. Each signer gets a unique single-use UUID, signing_url and qr_page_url (same request, two views). Links expire after 25 minutes; captured ink is private for at most 45 minutes after submission. No email is sent. Creator can show the QR page on a phone; signer may scan it or choose Sign on this phone. Existing signature assets are refused so previews never expose another person's signature. Call signature_request_get for status; replace one slot with signature_request_replace. No signature image download is provided.

Parameters2

document	object	required	Complete document with named, unfilled signature slots
slot_ids	array	required	Exactly the signature slot IDs to request; other slots remain untouched

Raw schema

{
  "properties": {
    "document": {
      "description": "Complete document with named, unfilled signature slots",
      "type": "object"
    },
    "slot_ids": {
      "description": "Exactly the signature slot IDs to request; other slots remain untouched",
      "items": {
        "type": "string"
      },
      "type": "array"
    }
  },
  "required": [
    "document",
    "slot_ids"
  ],
  "type": "object"
}

signature_request_get

Get owner-only status for a signing collection: document revision, requester, each signer/slot, status, deadlines and pending signing/QR URLs. No signature image, reusable asset reference or signed preview is returned. REST status endpoints are available per UUID for webpages.

Parameters1

string

required

Signing collection ID

Raw schema

{
  "properties": {
    "id": {
      "description": "Signing collection ID",
      "type": "string"
    }
  },
  "required": [
    "id"
  ],
  "type": "object"
}

signature_request_replace

Request a new signature for ONE person/slot on the same frozen document. Always creates a new UUID and 25-minute deadline, revokes the old request and deletes its captured ink. Other signers are unchanged. No email is sent automatically.

Parameters2

id	string	required	Signing collection ID
slot_id	string	required	Exact signer slot to replace

Raw schema

{
  "properties": {
    "id": {
      "description": "Signing collection ID",
      "type": "string"
    },
    "slot_id": {
      "description": "Exact signer slot to replace",
      "type": "string"
    }
  },
  "required": [
    "id",
    "slot_id"
  ],
  "type": "object"
}

signature_request_revoke

Withdraw one signer request or the whole collection and delete its temporary signature material. Existing issued PDFs are not changed.

Parameters2

id	string	required	Signing collection ID
slot_id	string	optional	One slot, or omit to revoke all

Raw schema

{
  "properties": {
    "id": {
      "description": "Signing collection ID",
      "type": "string"
    },
    "slot_id": {
      "description": "One slot, or omit to revoke all",
      "type": "string"
    }
  },
  "required": [
    "id"
  ],
  "type": "object"
}

signature_request_render

Explicitly render and issue the completed document after ALL selected signing slots are completed and their ink is unexpired. Returns a document URL, never raw signature downloads. This keeps an issued PDF containing the signatures; temporary signature capture still expires after 45 minutes. May re-render during retention. Does not send email. finalize:true deletes captured ink immediately after successful issue, preventing subsequent re-rendering.

Parameters2

finalize	boolean	optional	Delete temporary signature ink after successful issue
id	string	required	Signing collection ID

Raw schema

{
  "properties": {
    "finalize": {
      "description": "Delete temporary signature ink after successful issue",
      "type": "boolean"
    },
    "id": {
      "description": "Signing collection ID",
      "type": "string"
    }
  },
  "required": [
    "id"
  ],
  "type": "object"
}

signature_request_email

Explicitly email ONE named signer's pending link through Pubmail's transactional lane. Alternative to showing qr_page_url; never automatically do both. Requires an authenticated creator account with an email address; a bare service identity cannot send invitations. Request has a fixed recipient after first send. Returns queued, sending, pending_review, failed or unknown, never claims inbox delivery. Duplicate calls do not send again. Limits: 20 invitations per creator/hour and 3 per recipient/hour. A refused or expired request needs a new UUID for that slot. No document or signature image is attached.

Parameters3

id	string	required	Signing collection ID
slot_id	string	required	Specific named signer slot
to	string	required	This signer's email address

Raw schema

{
  "properties": {
    "id": {
      "description": "Signing collection ID",
      "type": "string"
    },
    "slot_id": {
      "description": "Specific named signer slot",
      "type": "string"
    },
    "to": {
      "description": "This signer's email address",
      "type": "string"
    }
  },
  "required": [
    "id",
    "slot_id",
    "to"
  ],
  "type": "object"
}

asset_upload_begin

Reserve an id for a mark — a signature, a logo, a seal, a letterhead — and get back the URL to POST the image to. THE ID COMES FIRST and the bytes follow: this call moves no image data. FORMATS: send PNG or JPEG. It is stored as PNG with transparency whatever you send. SVG is refused — export it to PNG first; at 300 dpi a vector mark loses nothing at print size. Ask for several at once with `slots`: a letterhead and a signature is ONE call, not two conversational turns. THE SLOT DECLARES THE SIZE — signature (62×12 mm), logo (50×14 mm), seal (28×28 mm), letterhead (80×18 mm). A larger upload buys a better-resolution mark in the same box, never a bigger one, so adding a signature never reflows a page. Near-white is keyed out to transparent on intake and the mark is trimmed to its ink, because a scan on white paper is an opaque rectangle that would cover the ruled line it sits on. Pass keep_background for a crest designed on a coloured field, which keying would destroy. Then POST the bytes; HTTP 202 means stored and processing asynchronously. Poll asset_status until ready or failed before rendering. HTTP 503 with Retry-After means capacity is busy; retry the same upload ticket. A ticket is single-use and expires in 30 minutes; a failed upload SPENDS it, so a retry needs a fresh begin.

Parameters3

keep_background	boolean	optional	Do not key out the background. For a mark designed on a coloured field.
slot	string	optional	One of: signature, logo, seal, letterhead
slots	array	optional	Several slots in one call, instead of `slot`.

Raw schema

{
  "properties": {
    "keep_background": {
      "description": "Do not key out the background. For a mark designed on a coloured field.",
      "type": "boolean"
    },
    "slot": {
      "description": "One of: signature, logo, seal, letterhead",
      "type": "string"
    },
    "slots": {
      "description": "Several slots in one call, instead of `slot`.",
      "items": {
        "type": "string"
      },
      "type": "array"
    }
  },
  "type": "object"
}

asset_status

Where a mark is: awaiting_upload, processing, ready, or failed with the reason. A document may reference a mark that is not ready yet — that is a normal transient state, not a validation failure. A FAILED mark is a validation failure, and the reason says what to fix.

Parameters1

string

required

The asset id from asset_upload_begin

Raw schema

{
  "properties": {
    "id": {
      "description": "The asset id from asset_upload_begin",
      "type": "string"
    }
  },
  "required": [
    "id"
  ],
  "type": "object"
}

services/doksi/README.md7 KBView on GitHub

Doksi — document and PDF MCP server for Claude, Cursor and any MCP client

Doksi turns a structured document into a professional PDF: personal and official letters, notices, agreements, ceremonial covenants, checklists, meeting agendas and schedules — and collects signatures by individual link or QR code. It runs as a hosted MCP server over HTTPS.


Endpoint	`https://doksi.publifye.com/mcp`
Transport	Streamable HTTP
Auth	OAuth 2.1 + PKCE (S256), DCR open
Registry	`pro.publifye/doksi` (server.json)
Product site	https://doksi.publifye.com
What it solves	https://publifye.com/doksi
Capability tools	30 (full schemas)

Connect

jsonc

{ "mcpServers": { "doksi": { "type": "http", "url": "https://doksi.publifye.com/mcp" } } }

Claude Code: claude mcp add --transport http doksi https://doksi.publifye.com/mcp, then /mcp to sign in. The discovery chain is the same as for the other servers: ../../docs/connect.md.

Ask what a kind requires before writing it

Most document tools accept a blob and fail at render. Doksi is built the other way round, and four of its thirty tools exist only so an agent can find out what is expected before it composes anything: kind_list names the document kinds, purpose_list the purposes, block_types the blocks a body may contain, and doc_requirements states what one specific kind demands.

That ordering is deliberate. An agent that can ask what a kind requires produces far fewer refusals than one that learns by being refused, and the difference shows up as fewer wasted calls rather than as better error messages.

doc_validate then checks a composed document without rendering it, so a draft can be corrected while it is still cheap.

Signatures are a request, not a field

Seven tools cover signing, and the shape is a request with its own lifecycle rather than a boolean on a document: create it, describe it, fetch it, replace it, revoke it, render it, and mail it. A signer receives an individual link or a QR code; a revoked link stops working; rotating a link does not invalidate the document it points at. A signing request can be made over a document you have already kept, by its id, and can be given an expiry.

What you have kept

An issued document is kept on your account. doc_list lists what you have kept, newest first, and doc_rename gives one a private name that is never printed on it or shown to anyone else. doc_delete stops its link, every temporary share link and every open signing request over it at once, and moves it to the trash; doc_trash lists what can still be restored and doc_restore brings it back within 7 days, with a new link. After that it is purged, and the purge is announced in advance.

Besides a plan or the daily allowance, a document can be paid for with a purchased credit: doc_credit_balance shows what is left and when each pack expires, and doc_compose_credit compiles one PDF against one credit. A refused document is never charged. doc_access_status says before you compose whether a covenant will come out print-ready or as a watermarked preview.

Marriage covenants: marriage.publifye.com

https://marriage.publifye.com is Doksi's website for marriage covenants. A couple, or their pastor or officiant, tells their own AI assistant what the covenant should say: both names, the date and place, each person's vow, a Bible verse and the witnesses. They choose one of twelve designs and get back a typeset one-page PDF in A4, or A3 for framing, to sign and hang on the wall.

Twelve designs. Seven painted in watercolour (Champagne Butterfly, Something Blue, Blush Petunias, Bridal Lilies, Garden Roses, Blue Iris, Ivory Magnolia), four drawn (Together in Bloom, Butterfly Garden, Hearts Entwined, Olive & Promise), and Star & Blossom, with a Star of David, made for a Jewish marriage.
The couple's own words. Each person writes their own vow. The 1662 Book of Common Prayer vows are there as an example of wording. The Bible verse is Ecclesiastes 4:12 unless the couple chooses one to three others, or none.
English and Norwegian. Sign in ink, or by a personal signing link or QR code.
A keepsake, not a certificate. Every covenant says at its foot that it is not a civil marriage certificate. A marriage is registered the way the couple's country requires.
Private. A finished covenant is emailed only to the account that asked for it, and its link is never listed or indexed.

There is no separate server to connect. The site uses the Doksi server above: the assistant calls doc_requirements with kind: covenant to learn the fields, then doc_compose with content.occasion: marriage. Designing, checking the wording and a full preview marked PREVIEW are free with a Publifye account. The print-ready covenant needs a 7-day marriage pass, a Doksi credit or a Doksi plan; current prices are on https://marriage.publifye.com/store.

What the tools do

Every tool is documented with its exact description, annotations and input schema — 30 in all, generated from the service's own tools/list, never written by hand.

Area	The question it answers	Tools
Catalogue	What kinds exist, and what does this one require?	4
Compose and validate	Is this document well formed, and what does it render to?	3
Issue, share and deliver	How does someone else get at it, and how do I take it back?	6
Signatures	Who still has to sign, and by which link?	7
Assets	How do I get a logo or a mark into a document?	2
Your documents	What have I kept, and how do I tidy or recover it?	5
Access and credits	Will it print clean, and what does it cost?	3

Machine-readable: tools.json carries all 30 with full JSON Schema, plus every excluded bucket listed by name so the count is auditable.

What it does not do

Not a word processor. Doksi renders structured documents of known kinds. It is not a place to lay out arbitrary pages.
Not a legal service. An agreement or covenant rendered here is a document, not advice, and a signature collected here is not a statement about its legal effect in any jurisdiction.
No silent coercion. A document that does not meet its kind's requirements is refused by doc_validate rather than rendered with the gaps filled in.

Plans

A free tier includes a small daily allowance. Plans and prices can change; the current ones are always on https://doksi.publifye.com, and where this page and the site differ, the site is right.

Install

Tools (22)

kind_listpurpose_listblock_typesdoc_requirementsdoc_validatedoc_composedoc_getdoc_issue

Remote endpoint

Streamable HTTP

Hosted server - connect over the network, no local install.

url

https://doksi.publifye.com/mcp

Add to VS Code Add to Cursor

claude_desktop_config.json

json

{
  "mcpServers": {
    "doksi": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://doksi.publifye.com/mcp"
      ]
    }
  }
}

Desktop config is stdio-only; this bridges via mcp-remote. Native remote: Settings > Connectors.

pro.publifye/doksi — Model Context Protocol (MCP) Server

🛠️ Key Features

🚀 Use Cases

⚡ Developer Benefits

⚠️ Limitations

Topics

kind_list

purpose_list

block_types

doc_requirements

doc_validate

doc_compose

doc_get

doc_issue

doc_share

doc_share_revoke

doc_link_rotate

doc_link_revoke

doc_mail_to_me

signature_describe

signature_request_create

signature_request_get

signature_request_replace

signature_request_revoke

signature_request_render

signature_request_email

asset_upload_begin

asset_status

Doksi — document and PDF MCP server for Claude, Cursor and any MCP client

Connect

Ask what a kind requires before writing it

Signatures are a request, not a field

What you have kept

Marriage covenants: marriage.publifye.com

What the tools do

What it does not do

Plans

Install

Remote endpoint

Related servers