The GroupDocs.Annotation MCP server runs in evaluation mode out of the box — no sign-up, no key. Your existing GroupDocs.Annotation license unlocks full functionality: point the installer’s licensePath — or the GROUPDOCS_LICENSE_PATH environment variable in a manual install — at your .lic file.
The MCP server itself is open source (MIT); the underlying GroupDocs.Annotation engine requires a license for production use.
There are three modes. The server takes the first one that is configured:
Metered wins. If both metered keys and a license file are configured, the server uses metered licensing and ignores the file — and says so in its startup log.
Evaluation mode limitations
Without a license:
Trial badges are placed in the document at the top of each page, so annotated output is not distributable.
Tool responses include an evaluation-mode notice, and the rendered previews carry the same badge.
An empty license path is always safe — the server logs a notice and continues in evaluation mode; it never errors because a license is absent.
Your license file is read from local disk by the local server process — like your documents, it never leaves your machine.
Metered (pay-per-use) licensing
Metered licensing bills you for what you actually process, which suits AI agents: their usage is bursty and hard to size in advance. It is configured with two environment variables — there is nothing to mount and no file to ship:
"env":{"GROUPDOCS_METERED_PUBLIC_KEY":"<your public key>","GROUPDOCS_METERED_PRIVATE_KEY":"<your private key>"}
One key pair covers every GroupDocs product and platform — the same pair you already use for the library works here, and the consumption it reports is account-wide rather than per server.
Warning
Both keys are required. With only one set, the server ignores the metered configuration and stays in evaluation mode — it reports this explicitly rather than failing silently. Check with get_license_status.
Warning
Metered mode needs outbound connectivity. Usage is reported to GroupDocs servers, so air-gapped or firewalled deployments must allow that egress — or use a license file instead. Only usage is reported; document content never leaves your machine.
Keeping the private key out of committed files
The private key is a secret, and client configurations are plain files on disk — a project-scoped .mcp.json is committed by convention. In order of preference:
Set both variables in your OS environment and leave them out of the client config entirely. A stdio server inherits its client’s environment, so this works in every client.
Reference them indirectly where the client supports it — Claude Code expands ${VAR}; VS Code uses ${env:VAR} and ${input:...}.
A literal value in a user-scoped config (for example ~/.claude.json) is acceptable for a single developer.
Never commit a literal key in a project-scoped .mcp.json.
With Docker, forward the two variables by name — -e VAR with no value copies it from the launching process, so the key never appears in the file:
On macOS, an app launched from Finder does not inherit variables exported in your shell profile. Use launchctl setenv, or start the client from a terminal.
Confirming which mode is active
Ask your agent “what is the license status of the annotation server?”. The get_license_status tool (server 26.9.0+) answers without processing a document:
If a key pair is rejected, the mode reverts to evaluation and the note field says why — for example “Metered keys were supplied but the engine rejected them (Authentication failed.)” — so a mistyped key surfaces here instead of as a trial badge on your annotated document.