laserfiche-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LF_PASSWORD | Yes | Service account password. | |
| LF_USERNAME | Yes | Service account username. | |
| LF_AUTH_MODE | Yes | Authentication mode, e.g., 'password'. | |
| LF_READ_ONLY | No | Set to 'false' to enable write tools. | true |
| LF_API_VERSION | No | API version (v1 or v2). | v1 |
| LF_REPO_API_URL | Yes | The URL of the Laserfiche Repository API server. | |
| LF_REPOSITORY_ID | Yes | The repository ID. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| laserfiche_entry_compareA | Diff two entries' attributes and (optionally) template field values. Use this instead of fetching both entries yourself and comparing by eye — it's a deterministic set comparison, not a judgment call, and it tells you exactly which of possibly dozens of fields disagree instead of making you scan two JSON blobs. Typical uses: "are these two copies of the contract actually the same?", "what changed between this record and the template version?", "did the import bring over every field?". Compares five entry attributes — A field present on one entry's template but absent on the other's is
reported separately ( Sibling tools: Returns |
| laserfiche_entry_search_contentA | Search document text and return the passages that matched. Use this whenever the question is about what documents say. Returns
the matched text itself — page number plus surrounding excerpt — from
Laserfiche's full-text index, which is where OCR output for scanned
documents lives. Usually answers without downloading anything; when an
excerpt shows the right document, follow up with
A bare Sibling tools: Returns |
| laserfiche_repository_listA | List the repositories this account can reach on the server. Never raises and never returns |
| laserfiche_field_definition_listA | List every field definition in the repository. Use before authoring a field query or field update — returns each
field's On failure returns |
| laserfiche_tag_definition_listA | List every tag definition in the repository. Use before |
| laserfiche_template_definition_listA | List template definitions in the repository. Discover template names (each item: |
| laserfiche_template_field_listA | Return one template's fields with full metadata, in a single call. Use before Returns |
| laserfiche_link_definition_listA | List the entry-link type definitions on this repository. Use before |
| laserfiche_audit_reason_listA | Return the audit-reason codes the authenticated user may supply. Use before an audited |
| laserfiche_document_get_textA | Download a document's server-extracted text (v2 servers only). Use for reading a document's contents: the text comes from Laserfiche's
own extraction pipeline (OCR for scans, upstream extraction for office
files). v1 servers have no endpoint for this — there, use
Returns |
| laserfiche_document_get_edocA | Inspect (info), read as text, or download (bytes) a document's edoc.
|
| laserfiche_document_find_duplicatesA | Find byte-identical documents in a folder tree and group them. Use this to answer "are there duplicate files in here?" or "how much
space would deduping this folder recover?" — it downloads nothing for
documents whose size doesn't collide with another's, and only hashes the
ones that do, so it's usually far cheaper than it sounds. This is a
read-only scan: it finds duplicates, it does not delete or merge them —
follow up with Two-pass approach: first probes every document's size (headers only, no bytes transferred); only documents that share a size with another are then downloaded and hashed (SHA-256). A repository of mostly-distinct documents therefore touches a small fraction of the tree on pass two. This is a single blocking call with no interim progress — for a large
Sibling tools: Returns |
| laserfiche_entry_search_naturalA | Two-mode search: get query-authoring guidance, then execute with auto-repair. Use when you need to author a Laserfiche query and don't know the
server's templates or field names. (For content questions, prefer
Mode A ( Mode B ( |
| laserfiche_entry_searchA | Run a raw Laserfiche search query and return matching entries. Use when you can already express the search in Laserfiche syntax. Prefer
Syntax: Returns |
| laserfiche_entry_search_by_nameA | Find entries by name pattern, optionally scoped to a folder path. Convenience wrapper over Returns the same shape as |
| laserfiche_folder_listA | List the immediate children (documents and subfolders) of a folder. For browse-style navigation from a known folder; the root is typically
ID 1. Resolve a path string first with Returns |
| laserfiche_entry_getA | Fetch one entry's metadata: name, type, path, template, page count. Does NOT return field values ( Returns |
| laserfiche_entry_get_by_pathA | Resolve a backslash-delimited Laserfiche path to its entry. Use when the user refers to a location by path. The returned Returns |
| laserfiche_field_values_getA | Read the template field values currently on an entry. For metadata questions ("what's the status?", "who's the reviewer?").
For the entry's own properties use Returns |
| laserfiche_task_get_statusA | Look up the status of an async operation by its token. Async tools ( Returns the server's task payload ( |
| laserfiche_task_waitA | Block until an async operation reaches a terminal state. Preferred over manual polling. Returns the same payload as
|
| laserfiche_task_updateA | Check or wait on an async operation.
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Most tools target distinct resources, and the search family is carefully differentiated (raw, by name, content, natural). However, task_get_status, task_wait, and task_update overlap significantly—task_update explicitly subsumes the other two—and document_get_text overlaps with document_get_edoc(mode="text"), making selection ambiguous.
All tools share the laserfiche_ prefix and mostly follow a <resource>_<action>_<qualifier> pattern, so the set is predictable. Minor inconsistency: 'definition_list' appears as a suffix in some tools while others use 'get' or 'field_list,' and search variants use different qualifier positions, but nothing is chaotic.
22 tools is at the high end of reasonable and each definition-lister has a distinct resource, so the count is not absurd. It feels heavier than necessary because three task tools and two document-text tools could be consolidated, and several definition listers are only useful if absent write tools existed.
The set covers search, retrieval, metadata, and definitions very well, but it is a read-only surface: there are no create/update/delete/import tools. Descriptions repeatedly reference absent write/async tools like delete_entry, copy_entry, assign_template, set_tags, and set_links, so workflows like cleaning up duplicates dead-end.