MCP Server

MCP Server (Model Context Protocol)

The MCP server lets Claude and other MCP-compatible AI assistants connect directly to your DocMgt site and work with your records and documents through natural language. Instead of switching to the DocMgt screens, a user can ask their AI assistant to find records, read or update fields, attach documents, and run Add-Ins, and the assistant carries out those actions by calling DocMgt's MCP tools. The MCP server runs inside DocMgt itself, so it uses the same security, the same tenant isolation, and the same audit trail as the rest of the product.

Security model

There are two layers of protection and both must be satisfied before any MCP tool can run. First, MCP must be enabled for your tenant by an administrator; it is turned off by default and the connection endpoint is not reachable until you enable it. Second, every MCP client must authenticate as a real DocMgt user using that user's normal credentials. The AI assistant gets exactly the access that the authenticating user has — the same record type security, field-level rights, document rights, search rights, and tenant boundaries that apply in the web application apply identically through MCP. There is no separate "MCP permission model" to configure and no way for an MCP client to exceed the rights of the user it signs in as.

Because the assistant acts as a specific user, the best practice is to create a dedicated DocMgt user for MCP access and give that user only the record type access and field rights it actually needs. Lock the user down to the minimum required, leave admin rights off, and use that account in your AI client's configuration rather than a real person's login. Every action the assistant takes is attributed to that user in the normal DocMgt logs, so you retain a complete audit trail.

You can authenticate the client in one of two ways: with that user's username and password, or — recommended — with an API token issued for that user. An API token is a long, revocable, optionally expiring credential that you generate once and paste into the client in place of the password, so the user's real password never lives in an integration's configuration; you can revoke a token at any time without changing the user's login, and an administrator can require tokens for API access on tenants where password-based API access has been turned off. An administrator generates tokens under Admin → Security → API Tokens; see API Tokens for details. Whichever credential you choose, the assistant still acts as that one user and inherits exactly that user's rights.

Enabling MCP

Open Admin, go to Main settings, and expand the AI Settings section. Turn on Enable MCP Server and save. While this switch is off, the MCP endpoint returns nothing and does not advertise its presence. Turning it on makes the endpoint reachable at the /mcp path of your tenant's address, for example

https://yourtenant.docmgt.cloud/mcp.

Connecting an AI client

In your MCP client (such as Claude Desktop or Claude Code), add a new connector that points to your tenant's /mcp address and supply the credentials of the user the assistant should act as — either that user's username and password, or an API token issued for that user. The client performs a one-time connection handshake, after which the DocMgt tools become available to the assistant. From that point you can ask the assistant to perform DocMgt tasks in plain language and it will choose and call the appropriate tools.

Configuring your client

The MCP server is a remote endpoint that authenticates each request with an Authorization header, and it accepts two header styles. The recommended style is an API token, sent as a Bearer header: the token is a single value (it starts with dmapi_) that you paste in as-is, with no encoding step. The alternative is HTTP Basic authentication, where the client sends the username and password as an Authorization: Basic header. You do not have to build either header by hand — most clients accept a token or a username and password directly, or accept a header line you paste in. The exact steps differ slightly per client, but the two things you always need are the same: your tenant's /mcp URL and the credential (token, or username and password) of the user the assistant should act as.

Claude Code (command line). Add the server with the HTTP transport and an auth header. Replace the URL with your tenant. With an API token (recommended), paste the token exactly as issued — no encoding:

claude mcp add --transport http docmgt https://yourserverurl/mcp \

--header "Authorization: Bearer dmapi_your_token_here"

To use a username and password instead, send a Basic header, where the value is the text USER:PASS encoded as Base64 (any "Base64 encode" tool produces it — the same encoding every browser uses for Basic authentication):

claude mcp add --transport http docmgt https://yourserverurl/mcp \

--header "Authorization: Basic <base64 of USER:PASS>"

Claude Desktop (config file). Claude Desktop reads its servers from claude_desktop_config.json (Settings > Developer > Edit Config). Because the endpoint is a remote HTTP server, point the bridge helper at your /mcp URL and pass the auth header. With an API token (recommended):

{

"mcpServers": {

"docmgt": {

"command": "npx",

"args": [

"-y", "mcp-remote",

"https://yourserverurl/mcp",

"--header", "Authorization: Bearer dmapi_your_token_here"

]

}

To use a username and password instead, replace the header line with "--header", "Authorization: Basic <base64 of USER:PASS>". Save the file and restart Claude Desktop; the DocMgt tools appear once the connection handshake succeeds.

You do not configure the individual tools anywhere. As soon as the client connects, it asks the server what tools exist, and the server describes each one — its name, what it does, and every parameter it takes — so the assistant learns the interface on its own. Your only job is to point the client at the right address with the right credentials; the assistant handles the rest.

What the assistant can do

The MCP server exposes a focused set of tools. For records, the assistant can list the record types you can access along with each type's fields, search for records by type and field values, retrieve a single record, create new records, update fields on existing records, and delete records. For documents, it can read a document and its metadata, retrieve a document's binary content, create a document on a record, update document metadata, upload file content, and delete documents. Small files are uploaded in a single step, while large files use a separate two-step upload that transfers the file straight into secure storage without sending the data through the AI assistant (described below under Uploading large documents). The assistant can also run a named Add-In against a record or document, which lets it trigger any automation you have configured as a REST / MCP Add-In. For workflow, it can work the signed-in user's workflow list: find assigned work items, take an item from a shared queue, reassign an item to another user or back to the step's default assignees, and complete, reject, or process an item along any of its routing options.

Every one of these actions is filtered by the signed-in user's rights, so the assistant can only see and change what that user is permitted to see and change.

Working with the workflow inbox

The workflow tools let an assistant move work through your processes exactly as a person would from the DocMgt screens. The assistant starts by searching the inbox, which returns the work items currently assigned to the signed-in user; it can narrow the search by workflow step name, by the associated record, or by field values on that record. Each work item comes back with its available routing options — the same buttons a user would see, such as Approve or Reject — and each option carries the identifier the assistant needs to act on it, so the assistant never has to guess how an item can be routed. From there the assistant can take an unassigned item to claim it for processing, reassign an item to a specific user or back to the step's default assignees, complete an item using the step's default complete button, reject it using the default reject button, or process it along any specific option by name or identifier. Completing, rejecting, or processing a work item runs the very same workflow that the web application runs, so every downstream action configured on that step — emails, field updates, routing to the next step, and any other automation — fires exactly as it would if a user had clicked the button themselves. Because the inbox is scoped to the authenticating user, an assistant can only see and act on the work items that user is assigned, and every routing action is attributed to that user in the workflow history.

Uploading large documents

When an assistant needs to attach a large file, DocMgt uses a secure upload that keeps the file data off the AI connection entirely. The assistant first asks DocMgt to begin an upload for a new document; DocMgt creates the document and returns a plain upload address for that specific document. The file is then transferred directly to DocMgt at that address, so the bytes stream straight into your tenant's document store rather than passing through the AI assistant — for files under 100 MB this happens in a single transfer, and for larger files DocMgt accepts the data in sequential pieces sent one after another to the same address, transparently reassembling them into the finished file. Finally the assistant tells DocMgt to finish the upload, at which point DocMgt confirms the file arrived and runs the same post-upload processing — text recognition, thumbnails, and any record type defaults — that a normal upload would. This path handles large documents such as long scanned PDFs or video files, up to 1 GB per file, well beyond the limit of the standard single-call upload. The upload is protected exactly like every other action the assistant takes: the transfer uses the same Project Title credentials the assistant connected with (a username and password or an API token), it is limited to the one document it was started for, and it is governed by that user's normal document permissions, so it can neither reach nor modify anything the user could not already access.

Notes and limits

Small file uploads are sent to DocMgt encoded as text in a single call and are limited to 25 MB per upload; larger files should use the two-step upload described above, which streams the file directly into your tenant's document store and supports documents up to 100 MB. Deleting records and documents is subject to the user's delete rights, and running an Add-In respects that Add-In's own filters and security rules. If MCP is later disabled for the tenant, all connected clients immediately lose access.

TIPS

Create a dedicated, locked-down DocMgt user for MCP rather than using a person's login — the assistant inherits exactly that user's rights, and every action is attributed to it in the audit trail.
Authenticate with an API token (Authorization: Bearer dmapi_…) rather than a password — issue it under Admin → Security → API Tokens, paste it into the client as-is, and revoke it any time without touching the user's login.
Use the two-step large upload for anything big (such as long scanned PDFs); it keeps file bytes off the AI connection and has no practical size limit.
Leave MCP off until you need it — the endpoint is invisible and unreachable while the switch is off.

NOTE ON (AI): The MCP server lets an external AI assistant act inside your tenant as the authenticating user. It requires MCP to be enabled by an administrator and may incur extra fees. Check with your sales rep for more information. Please verify all results, as AI can make mistakes.