laserfiche-mcp

laserfiche_entry_search

Run raw Laserfiche search queries to find matching repository entries and return their IDs, names, paths, and optional web links.

Instructions

Run a raw Laserfiche search query and return matching entries.

Use when you can already express the search in Laserfiche syntax. Prefer search_content when the question is about what documents say (it returns the matched passages); search_natural when you need the grammar and available template/field names first; search_by_name for a simple name pattern.

Syntax: {LF:Name="Onboarding*"} name pattern; {LF:Basic~="phrase"} content search over document text/OCR, fields, annotations and names (,option="D" = document text only); {[Template]:[Field]="value"} field match; {LF:LookIn="\Path"} folder scope; combine clauses with & / |.

Returns entries (id, name, entry_type, full_path), total_count, next_link. Each entry also carries web_url — a link into the Laserfiche web client — when LF_WEB_CLIENT_URL_TEMPLATE (and, for folders, LF_WEB_CLIENT_FOLDER_URL_TEMPLATE) is configured; omitted otherwise. Prefer handing the user web_url over reading the document with get_document_edoc when they just want to open or download it themselves. On failure returns {"mode": "error", "error": <slug>} (server_error is common — this endpoint is fragile on some builds; see docs/error-contract.md).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	Laserfiche search expression. Each clause wrapped in braces and combined with `&` (AND) or `\|` (OR). Quote string values with double quotes; escape inner quotes with `\"`.
`max_results`	No	Page size. Defaults to LF_MAX_RESULTS_DEFAULT (25). Capped at LF_MAX_RESULTS_CEILING (typically 200).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.3.0Sep 21, 2026

changedInput schema / properties / query / examples

Previous value: -[
-  "{LF:Name=\"*.pdf\"}",
-  "{LF:Name=\"Onboarding*\"} & {LF:LookIn=\"\\\\Imports\\\\2024\"}",
-  "{[Loan Application]:[Last Name]=\"Smith\"}"
-]New value: +[
+  "{LF:Name=\"*.pdf\"}",
+  "{LF:Basic~=\"unpaid balance\",option=\"D\"}",
+  "{LF:Name=\"Onboarding*\"} & {LF:LookIn=\"\\\\Imports\\\\2024\"}",
+  "{[Loan Application]:[Last Name]=\"Smith\"}"
+]

First observedv2.1.0Jun 22, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it documents the error contract ({"mode": "error", "error": <slug>}), warns that server_error is common because the endpoint is fragile on some builds, and explains that web_url is conditionally present depending on LF_WEB_CLIENT_URL_TEMPLATE. It stops short of stating permissions/read-only nature or rate-limit behavior, which keeps it out of the top band.

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 definition is front-loaded with purpose, then alternatives, then syntax, then return/error shape. The syntax paragraph is dense but earns its place; minor redundancy exists in re-explaining return fields when an output schema is present.

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

Completeness4/5

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

For a two-parameter search tool with an output schema, the description covers the query grammar, sibling routing, config-dependent fields, and failure modes. It restates the return shape despite the output schema, which is slightly redundant but not harmful; nothing an agent needs 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.

Parameters4/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, but the description adds genuine meaning beyond the schema: it enumerates the clause forms ({LF:Name=...}, {LF:Basic~=...} with option="D" = document text only, {[Template]:[Field]="value"}, {LF:LookIn=...}) and how to combine them. That goes past the schema's generic 'wrap clauses in braces, combine with & or |' note.

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 opening sentence names a specific verb and resource ('Run a raw Laserfiche search query and return matching entries') and immediately distinguishes the tool from three named siblings (search_content, search_natural, search_by_name) with the condition that selects each. An agent can pick this tool without opening any schema.

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?

It gives an explicit use condition ('when you can already express the search in Laserfiche syntax') plus a routing rule for each alternative: search_content for what documents say, search_natural when the grammar/field names are unknown, search_by_name for simple patterns. There is also a follow-on rule for preferring web_url over get_document_edoc.

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