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.

Claude Desktop

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.

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.

`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. 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.

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.

License

MIT.

Available Tools

4 tools

create_requestCreate and send a Document RequestA

Call this when the Professional wants to ask a Client for documents: it creates the Document Request and sends the email in one step, so nothing is left created but unsent. Provide the Client email, a deadline, and the list of documents wanted, plus an optional title and a message written by the Professional. 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.1/5.0

Behavior5/5

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

With readOnlyHint=false, the description appropriately implies a mutation. It goes beyond annotations by disclosing the exact behavior: the email is sent immediately to the specified recipient only, and the client uploads via a secure link. It also warns about error behavior, naming the created request if email fails, which is valuable context not available from the schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the primary use, and covers both the main action and edge cases in just three sentences. It could be slightly more structured (e.g., bullet points for parameters), but it is efficient and to the point.

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?

The description is complete given the schema and output schema absence. It explains the core purpose, the recipient scope, the one-step behavior, and error handling. The schema already covers parameter details, so nothing essential is missing for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for all parameters, so the description does not need to add much, and it does not. It explains the purpose of recipient_email, deadline, and documents in the context, but doesn't add detail beyond what the schema already provides. However, note that 3 parameters are not required (title, message, recipient_name) and the description mentions 'optional title and a message', which adds slight contextual meaning. Yet because the schema descriptions already fully cover all parameters, the description adds minimal value, so it sits at baseline 3.

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?

This description clearly states what the tool does: it creates and sends a Document Request in one step. The verb 'create and send' is specific, and it identifies the resource (Document Request) and the action (emailing it). The title and description effectively differentiate it from siblings like 'get_request' or 'download_documents', which have different purposes.

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 explicitly tells the agent when to call this tool: when the Professional wants to ask a Client for documents. It also specifies the one-step nature (create and send) to avoid leaving requests unsent Poisson. However, it does not explicitly mention when not to use it or alternative tools (e.g., if the Professional wants to draft without sending, such as with 'request_replacement'), so it is slightly less than a 5.

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 itself, and 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?

The description discloses key behavioral traits beyond the annotations: it flags every rejected file, moves the request back to awaiting the Client, returns it to the automatic reminder cadence, does not email anything itself, and keeps the optional message in the audit trail rather than sending it. This is rich, accurate context that matches the annotations.

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 compact and well-structured. It front-loads the trigger condition, describes the immediate effects, clarifies the email behavior, and closes with an explicit negative usage note. Every sentence earns its place without redundancy.

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?

Given the simple two-parameter schema.rand With no output schema, the description fully covers what an agent needs to invoke the tool correctly: when to use it, what side effects occur, what the message field does, and how to avoid misuse. No important gap remains.

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 baseline is 3. The description reinforces that the message is not sent to the Client)Skip, but it does not add meaningful parameter semantics beyond what the schema already documents for request_id and message.

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 clearly states the action: call this when a Document Request has rejected files and the Professional wants the Client to resend them. It specifies the resource and the exact state change (flags rejected files, moves request back to awaiting the Client, returns to reminder cadence), distinguishing it from sibling read-only tools like get_request.

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?

Explicitly gives the precondition for use: a Document Request with rejected files and a Professional wanting the Client to send them again. It also states a clear exclusion: do not use on a request with no rejected file, and points to get_request as the way to check which files were rejected.

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.4/5.0

Scored 2026-09-14 18:56 across 4 tools

Disambiguation5/5

Each tool maps to a distinct action: create a new request, request replacement of rejected files, read request status, or download collected documents. The descriptions clearly state when not to use a tool, so there is little risk of selecting the wrong one.

Naming Consistency5/5

All tools follow a consistent imperative verb_noun pattern: create_request, request_replacement, get_request, download_documents. The names clearly signal the action and object, and the pattern is maintained throughout the small set.

Tool Count5/5

Four tools is well-scoped for the focused document-request workflow; each tool covers a necessary step: create, monitor, re-request, and download. There is no redundancy or overlap, so the small count feels deliberate rather than thin.

Completeness3/5

The core flow of requesting documents, checking status, re-requesting rejected files, and downloading is covered, but there is no general update or cancel/delete tool for a request. A Professional cannot adjust a deadline, change the document list, or withdraw a request through the MCP, which leaves a notable lifecycle gap.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

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
162
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
30 npm
MIT
docflow-mcp
AI & Machine Learning Legal & Compliance
intsig-textin
A
license
Not graded
quality
C
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)
MIT
MCP Document & Task Server
Project Management Knowledge & Memory Search
deepujain
A
license
B
quality
D
maintenance
Provides a document database with search, retrieval, and creation tools, and a task tracker with search and status filtering, enabling AI agents to manage documents and tasks via natural language.
Updated 6 months ago (2026-03-24 16:28 UTC)
3
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)
17 npm
MIT

dokutrak-mcp

Install

Claude Desktop

Claude Code

claude.ai

From a clone, before the npm release

Configuration

Tools

create_request

request_replacement

get_request

download_documents

What the connector cannot do

Development

License

Available Tools

TDQS

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

layerone-mcpofficial

docflow-mcp

MCP Document & Task Server

documenteroofficial

`create_request`

`request_replacement`

`get_request`

`download_documents`