What can you do with this server?

A stateless MCP connector for DokuTrak that lets an agent ask clients for documents, chase rejected files, check request status, and collect uploads. * create_request: Create and send a Document Request in one call — client email, deadline, checklist, optional title/message; the email goes only to the given recipient, and the tool requires confirmation before sending. * request_replacement: Chase a client on rejected files — flags rejected files, moves the request back to awaiting client, and restores automatic reminders; no email sent by this call, optional message recorded in audit trail. * get_request: Look up a request by ID or search term (title, client name, or email) to see status, checklist, collected files with verdicts, and reminder state. * download_documents: Get all collected documents of a request as one zip archive embedded as binary content in the tool result (no disk writes). * Not supported: approving/rejecting documents, billing, workspace settings, API key management; revocation takes effect on next call.

How do I use dokutrak-mcp?

1. Click on "Deploy 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., "@dokutrak-mcp What's the status of the Dupont file?" 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.

dokutrak-mcp

by Crackx17

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

dokutrak-mcp

The open MCP connector for DokuTrak: let your agent chase the documents.

DokuTrak collects documents from your clients on your behalf: you send a request, the client uploads through a secure link, the files are reviewed, and silent clients get reminded. This connector puts that loop inside the agent you already work in, so "where does the Dupont file stand?" is answered without leaving Claude.

The connector is a thin, stateless client of the DokuTrak API. It holds the Agent Connection you give it, stores nothing on disk, keeps no cache, and duplicates no rule: what your agent may and may not do is decided by the service, and refusals come back as tool errors with the service's own explanation.

Install

You need a DokuTrak workspace and an Agent Connection, issued from Settings → Connect an agent in the DokuTrak app. That screen hands you a paste-ready configuration with your key already in place; the instructions below are the same thing, by hand.

The key is read from the environment variable DOKUTRAK_API_KEY. It is never taken from the command line.

Install in Claude Desktop (one click)

Download dokutrak.mcpb, the connector packaged as an MCP Bundle.
Double-click it, or drag it onto Claude Desktop (Settings → Extensions).
Click Install and paste your Agent Connection key when asked. Claude Desktop masks it, stores it securely and passes it to the connector as DOKUTRAK_API_KEY.

The bundle carries its own copy of the connector and runs on the Node.js built into Claude Desktop: no npx, no configuration file to edit. npm run bundle builds the same file from a clone.

Claude Desktop, by hand

Open the configuration file:

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

Add the server under mcpServers (create the object if the file is empty):

{
  "mcpServers": {
    "dokutrak": {
      "command": "npx",
      "args": ["-y", "dokutrak-mcp"],
      "env": { "DOKUTRAK_API_KEY": "dk_live_…" }
    }
  }
}

Restart Claude Desktop. The DokuTrak tools appear in the tools menu of a new conversation.

Claude Code

claude mcp add dokutrak -e DOKUTRAK_API_KEY=dk_live_… -- npx -y dokutrak-mcp

Then /mcp inside Claude Code lists dokutrak and its tools.

claude.ai

Not supported in this release. claude.ai connects to remote MCP servers over HTTP with OAuth; this connector speaks stdio with an API key, which is what a local install into Claude Desktop or Claude Code needs. A hosted variant is a separate, later decision.

From a clone, before the npm release

git clone https://github.com/Crackx17/dokutrak-mcp.git
cd dokutrak-mcp
npm ci && npm run build

Then point the client at the built file instead of npx:

{
  "mcpServers": {
    "dokutrak": {
      "command": "node",
      "args": ["/path/to/dokutrak-mcp/dist/cli.js"],
      "env": { "DOKUTRAK_API_KEY": "dk_live_…" }
    }
  }
}

or, for Claude Code: claude mcp add dokutrak -e DOKUTRAK_API_KEY=dk_live_… -- node /path/to/dokutrak-mcp/dist/cli.js.

The skill

skills/dokutrak/SKILL.md teaches the agent the three everyday uses — ask a Client for documents, know where a request stands, chase on rejected files — and how to connect. It is what a DokuTrak user installs alongside the connector:

npx skills add Crackx17/dokutrak-mcp        # the open agent-skills installer
# or by hand, for Claude Code / Claude Desktop:
cp -r skills/dokutrak ~/.claude/skills/dokutrak

Related MCP server: docflow-mcp

Configuration

Variable	Required	Default	Meaning
`DOKUTRAK_API_KEY`	yes	—	The Agent Connection, from Settings → Connect an agent.
`DOKUTRAK_API_URL`	no	`https://app.dokutrak.com/api`	Base URL of the API. Ends in `/api`; the connector adds `/v1`.

Tools

Four tools, one round trip: ask, chase, know, collect.

`create_request`

Creates a Document Request and sends it, in one call, so nothing is left created but unsent. Takes the client's email, a deadline (YYYY-MM-DD or an ISO datetime), the checklist of documents wanted, and an optional title and message. The email goes to the recipient given here and to nobody else; the client uploads through the secure link it contains. Under the hood this is the same two-step the DokuTrak app performs: create with sendEmail: false, then send. If the send fails, the error names the created request, which stays visible in the dashboard.

Nothing goes out without your yes. The email to a real client cannot be recalled, so the tool tells the agent to show you the recipient, the deadline, the checklist and the message, and to wait for your confirmation. The tool is also flagged so that the client asks you before every call: Claude Code prompts each time, even in auto or bypass mode, and Claude Desktop treats it as a tool that always needs approval. A client that ignores these flags is left with the instruction to the agent alone.

`request_replacement`

Chases the client on the rejected files of a request: flags them, moves the request back to awaiting the client, and returns it to the automatic reminder cadence. This call sends no email by itself; the reminders do, and DokuTrak has no way to email the client immediately, not even from the dashboard. The optional message is recorded in the request's audit trail and is not sent to the client. It refuses a request with no rejected file.

`get_request`

Where a Document Request stands, in one call: status, the checklist, every collected file with its verdict (approved, rejected with the reviewer's reason, or pending), and the reminder state. Give a request_id, or a search term matching the title or the client's name or email. When several requests match, the tool returns the candidates and asks for the id.

`download_documents`

Every collected file of a request, as one zip archive. The archive comes back embedded in the tool result as binary content (an MCP resource with a base64 blob and application/zip), not as a link: the API has no short-link endpoint for a zip, and the connector writes nothing to disk. What the agent does with the bytes is decided on the professional's side, exactly like a download from the browser. Large archives make large results; check with get_request that documents have arrived before calling it.

What the connector cannot do

Approving or rejecting a document is your decision, taken in the DokuTrak dashboard. No tool here can take it, and the service refuses it to any Agent Connection regardless of which connector asks. The same goes for billing, workspace settings and the management of API keys.

Revoking the Agent Connection in DokuTrak takes effect on the very next call: the connector answers with the service's 401 and nothing else.

Privacy Policy

The connector runs on your machine and talks to one service only: the DokuTrak API (https://app.dokutrak.com/api, or the URL you set in DOKUTRAK_API_URL), with the Agent Connection you configured. It sends what the tools need (the request you create, the id or search term you look up) and relays the answers to your agent. It writes nothing to disk, keeps no cache or log, and sends no telemetry or analytics to DokuTrak or to anyone else.

Everything it sends is processed by DokuTrak under the DokuTrak Privacy Policy, which covers what is collected, how it is used and stored, the subprocessors it is shared with, retention and deletion, and your rights. Questions: arthur@dokutrak.com; security issues: security@dokutrak.com.

Development

npm ci
npm run check   # typecheck, build, tests
npm test        # tests alone

The tests are contract tests at the MCP seam: a real MCP client and the real server, connected in memory through the official SDK's transport, with HTTP stubbed at fetch using recorded responses. They call tools, never functions, and run with no DokuTrak account and no network.

The staging run

Before a release, the built binary is driven once against a real workspace, by a real MCP client over stdio: create → chase → read → collect → revoke → 401. It is a record pasted into the release PR, never a CI check (a blocking check calls no third party). It pauses twice for acts the service refuses to any Agent Connection: rejecting the uploaded file, and revoking the key.

npm run build
DOKUTRAK_API_KEY=dk_live_… STAGING_RECIPIENT_EMAIL=you@example.com npm run staging

A real Document Request is created and a real email goes to STAGING_RECIPIENT_EMAIL. The transcript lands in staging-run-<timestamp>.md (git-ignored); the key is never written to it.

The MCP Bundle

npm run bundle builds mcpb/server/index.cjs (the connector with every dependency inlined), starts it and checks that it lists exactly the tools declared in mcpb/manifest.json at the version of package.json, then validates the manifest and packs dokutrak.mcpb with the official mcpb CLI. CI runs it on every pull request, and the release workflow attaches dokutrak.mcpb to the GitHub release of each tag. A change to the tool surface or the version updates mcpb/manifest.json too.

Releasing

A tag vX.Y.Z matching package.json and SERVER_VERSION triggers .github/workflows/release.yml: npm run check, npm publish (trusted publishing through GitHub's OIDC token, provenance attached), then the listing in the MCP Registry as io.github.Crackx17/dokutrak-mcp — the mcpName of package.json, which the registry checks against the published tarball. Running the workflow by hand does a --dry-run and publishes nothing.

License

MIT.

Available Tools

4 tools

create_requestCreate and send a Document RequestA

Destructive

Call this when the Professional wants to ask a Client for documents: it creates the Document Request and emails the Client in one step, and that email cannot be recalled. Before calling, show the Professional the recipient email, the deadline, each document as the Client will read it, and the message if there is one, then call only once they have confirmed, even when the request already looks complete. The email goes to the recipient given here and to nobody else, and the Client uploads through the secure link it contains. If the email fails after creation, the error names the created request so it can be sent from the dashboard.

ParametersJSON Schema

Name	Required	Description
`title`	No	Title of the request, as the Professional names the file.
`message`	No	A message from the Professional to the Client, included in the email.
`deadline`	Yes	When the documents are due. A date (YYYY-MM-DD) or an ISO 8601 datetime.
`documents`	Yes	The checklist the Client must fill.
`recipient_name`	No	How the Client is addressed in the email.
`recipient_email`	Yes	The Client who must upload the documents. The only address the email will go to.

TDQS

A4.5/5.0

Behavior5/5

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

The annotations already mark this as destructive, non-idempotent, and open-world, and the description adds critical behavioral context: the email cannot be recalled, it goes only to the provided recipient, the Client uploads through a secure link, and a post-creation email failure returns an error naming the created request. This is exactly the kind of disclosure an agent needs for a risky one-shot mutation.

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 front-loaded with the core action and irreversibility warning, then moves efficiently through confirmation workflow, recipient scope, upload behavior, and failure handling. Despite its length, every sentence carries operational weight for a destructive tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, externally visible creation tool with no output schema, the description covers the essential workflow, safety warning, recipient scope, and failure mode. An agent has enough context to call it correctly once the user has confirmed.

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 description coverage is 100%, so the schema already documents all six parameters in detail. The description reinforces some key inputs, such as showing the recipient email and documents as the Client will read them, but adds little syntax or format meaning beyond what is already in the schema.

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 states a specific verb and resource: it creates a Document Request and emails the Client in one step. This clearly distinguishes the tool from read/download siblings like get_request and download_documents, even though it does not explicitly name alternatives.

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 gives strong invocation guidance: call when the Professional wants to ask for documents, first show the recipient, deadline, documents, and message, then call only after confirmation. It does not explicitly discuss when not to use this tool or name alternative sibling tools such as request_replacement.

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

download_documentsCollect the documents of a Document RequestA

Read-only

Call this when the Professional wants the files a Client has uploaded on a Document Request, for example to file them or read them locally. It returns every collected document as one zip archive, embedded in the result as binary content. The archive is the same download the dashboard offers and comes back only to the agent of the Professional, never to a third party. Use get_request first to check that documents have actually arrived.

ParametersJSON Schema

Name	Required	Description	Default
`request_id`	Yes	The Document Request whose collected files are wanted.

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavioral context: results are delivered as a zip archive embedded as binary content, the archive matches the dashboard download, and it is returned only to the agent of the Professional, never to a third party. This goes well beyond what annotations convey.

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?

Three sentences front-load the usage trigger, then efficiently cover output format, access scope, and a prerequisite. Every sentence contributes useful information, with no filler or repeated schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only tool with no output schema, the description is complete: it explains when to call it, what the result looks like, what scope of data is included, who can receive it, and what to check beforehand. Nothing essential is missing for correct invocation.

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% and the single parameter request_id is already described as 'The Document Request whose collected files are wanted.' The tool description reinforces that the files belong to a Document Request, but it does not add substantial new parameter-level meaning beyond the schema.

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 names a specific action (collect/download) and resource (files uploaded on a Document Request), and clarifies the concrete output: a zip archive of all collected documents. It is clearly distinguishable from siblings like create_request and request_replacement, and it positions itself relative to get_request as a prerequisite check.

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?

It opens with an explicit invocation condition ('Call this when the Professional wants the files a Client has uploaded...') and adds a practical prerequisite ('Use get_request first to check that documents have actually arrived'). It does not explicitly state when not to use the tool or name alternative tools beyond get_request, so it falls just short of full guidance.

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

get_requestWhere does a Document Request standA

Read-only

Call this when the Professional asks where a Document Request stands: which documents arrived, which were approved or rejected, and when the Client was last chased. Give the request id when you have it, or a search term matching the title, the Client name or the Client email; several matches come back as a short list to choose from. One call returns the status, the checklist, every collected file with its verdict, and the reminder state, so no follow-up read is needed. Approving or rejecting a document is the decision of the Professional, made in the DokuTrak dashboard, and no tool here can take it.

ParametersJSON Schema

Name	Required	Description	Default
`search`	No	Text to match against the request title, the Client name or the Client email, when the id is not known.
`request_id`	No	The id of the Document Request, when known.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context: one call returns everything with no follow-up read needed, search may return multiple matches as a short list, and approval/rejection is intentionally outside the tool's capability. This goes well beyond the annotation baseline.

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 front-loaded with the core trigger and purpose, then explains parameter usage, return completeness, and a key boundary. Every sentence adds distinct value, and the structure is easy for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description fully covers what the agent needs: when to call it, how to identify the request, what the response contains, and what it cannot do. The optional parameter relationship is clearly explained, making the tool self-contained.

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 description coverage is 100%, so the schema already documents both parameters. The description adds practical usage semantics: request_id is preferred when known, while search matches title, Client name, or Client email and can yield multiple options. This supplements the schema without redundancy.

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 opens with a specific trigger and resource: 'Call this when the Professional asks where a Document Request stands.' It clearly enumerates what the tool returns—status, checklist, files with verdicts, and reminder state—making it distinct from siblings like create_request or download_documents.

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 gives explicit conditions: use this for status questions, provide the request id when known, or fall back to a search term matching title, Client name, or Client email. It does not explicitly name alternatives like 'use create_request instead', but the trigger context and the statement that no tool can approve/reject provide adequate guidance.

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

request_replacementChase the Client on rejected filesA

Idempotent

Call this when a Document Request has rejected files and the Professional wants the Client to send them again. It flags every rejected file, moves the request back to awaiting the Client, and returns it to the automatic reminder cadence, which is what reaches the Client. Nothing is emailed by this call and there is no way to email the Client immediately, not even from the dashboard; the optional message is kept in the audit trail rather than sent. Do not use it on a request with no rejected file; get_request shows which files were rejected.

ParametersJSON Schema

Name	Required	Description	Default
`message`	No	A note from the Professional, recorded in the audit trail of the request. Not sent to the Client.
`request_id`	Yes	The Document Request whose rejected files must be sent again.

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the state transitions, that nothing is emailed here, that no immediate-email path exists even from the dashboard, and that the message is audit-only. These are non-obvious behavioral facts an agent would otherwise assume incorrectly.

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?

Front-loaded with the trigger, then constraints and the negative capability note, then the exclusion. Every sentence carries a distinct, useful fact; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description explains the resulting request state and that there is no return-value surprise. For a two-parameter mutation with full schema coverage and clear annotations, nothing needed to call it correctly is missing.

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 description coverage is 100% and the schema already states the message is audit-trail-only, so the description largely reinforces existing field docs. Baseline 3 is appropriate; no syntax or format detail is added beyond the schema.

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?

States a specific action and resource: it flags rejected files, moves the request back to awaiting the Client, and restores the reminder cadence. An agent can distinguish it from siblings because it names get_request as the read counterpart and describes a distinct mutation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger (a request with rejected files where the Professional wants a resend) plus an explicit exclusion ('Do not use it on a request with no rejected file') and a named alternative (get_request shows which files were rejected). Nothing is left to inference.

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.

4 tool updatesv0.1.0Sep 14, 2026
- First observedcreate_request
- First observeddownload_documents
- First observedget_request
- First observedrequest_replacement

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored 2026-09-30 14:00 across 4 tools

Disambiguation5/5

Each tool serves a clearly distinct purpose: create_request creates and emails, get_request retrieves status, download_documents fetches files as a zip, and request_replacement re-requests rejected files. The descriptions explicitly distinguish their use cases and boundaries, leaving no room for confusion.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: create_request, get_request, request_replacement, download_documents. The convention is predictable and readable throughout.

Tool Count5/5

Four tools are well-scoped for the core agent workflows of document request management. Each tool earns its place with no redundancy, and the set avoids both oversupply and critical under-supply.

Completeness4/5

The set covers creating, tracking, downloading, and re-requesting documents, which covers the main agent actions. However, there is no tool to list all requests without a search term, nor to update request details (e.g., deadline), representing a minor gap.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

zsign AOAuth
io.zsign
E-signature API for AI agents: send contracts, sign PDF documents, track and download signed files.
Legal & Compliance Payments & Billing
222
Prismism B
dev.prismism
Upload any file, get a tracked shareable link. DocSend for AI agents.
Cloud Storage File Systems App Automation
2
ragie
com.mcparmory
Ingest, manage, and retrieve documents for RAG-powered AI applications
RAG Systems Databases Knowledge & Memory
2
Cotribute MCPOAuth
com.cotribute
Connect AI agents to financial institution origination, analytics, and compliance workflows.
Finance CRM
2

Related MCP Servers

layerone-mcpofficial
Payments & Billing Legal & Compliance
GOLayerone
A
license
A
quality
D
maintenance
Enables AI agents to generate documents (PDF/DOCX/Factur-X) and manage electronic signatures (eIDAS/PAdES) via natural language using LayerOne's DocX and Sign APIs.
Updated 3 months ago (2026-06-18 19:23 UTC)
20
33 npm
MIT
docflow-mcp
AI & Machine Learning Legal & Compliance
intsig-textin
A
license
B
quality
D
maintenance
Enables LLM agents to classify documents, extract fields, tables, and stamps, and run compliance reviews using Docflow's document automation platform via 41 MCP tools.
Updated 6 months ago (2026-03-25 03:54 UTC)
41
MIT
documenteroofficial
Workplace & Productivity App Automation
documentero
A
license
Not graded
quality
C
maintenance
Enables AI agents to list Documentero templates, inspect their field schemas, and generate Word/PDF/Excel documents via the Documentero API.
Updated 2 months ago (2026-07-24 14:52 UTC)
32 npm
MIT
@docmake/mcpofficial
Workplace & Productivity App Automation
docmake-io
A
license
A
quality
B
maintenance
Enables AI assistants to generate DOCX and PDF documents from DocMake templates through natural language, including template listing, field inspection, document rendering, DOCX import, and usage tracking.
Updated a month ago (2026-08-31 13:59 UTC)
6
33 npm
MIT

dokutrak-mcp

Install

Install in Claude Desktop (one click)

Claude Desktop, by hand

Claude Code

claude.ai

From a clone, before the npm release

The skill

Configuration

Tools

create_request

request_replacement

get_request

download_documents

What the connector cannot do

Privacy Policy

Development

The staging run

The MCP Bundle

Releasing

License

Available Tools

TDQS

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

layerone-mcpofficial

docflow-mcp

documenteroofficial

@docmake/mcpofficial

`create_request`

`request_replacement`

`get_request`

`download_documents`