laserfiche-mcp

laserfiche_entry_search_natural

Author Laserfiche queries: get guidance with templates, then execute with auto-repair to find entries.

Instructions

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 search_content; for a query you can already write, search_entries.)

Mode A (lf_query omitted): returns mode="guidance" with the search grammar, discovered_templates (names + field names sampled from folder_path or the root), and up to 3 candidate_queries. Pick or refine one, then call again with lf_query.

Mode B (lf_query given): executes it. On HTTP 400 it retries with up to two automatic repairs (escape inner quotes; wildcard-wrap bare Name= values when fuzzy=True), then returns mode="error" with every attempts entry (query, repair, status, server body) so you can author a fresh query. Success returns mode="results", with each entry carrying web_url when LF_WEB_CLIENT_URL_TEMPLATE is configured; pagination_unknown=true means the server hit the cap without saying whether more exist.

Input Schema

TableJSON Schema

Name	Required	Description
`fuzzy`	No	Allow the wildcard-wrap repair on 400 (default). Set False for exact-match queries that must not be relaxed.
`lf_query`	No	Laserfiche query to execute (Mode B). Omit to get guidance (Mode A): grammar reference, sampled templates, candidate queries to refine.
`question`	Yes	The user's natural-language search question.
`folder_path`	No	Backslash-delimited folder path. In Mode A, narrows the template sample to this subtree; in Mode B, the LLM should embed {LF:LookIn="<path>"} in lf_query itself if scoping is wanted.
`max_results`	No	Page size, clamped to LF_MAX_PAGE_SIZE (default 100).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv2.3.0Sep 21, 2026

changedInput schema / properties / fuzzy / description

Previous value: -"When True (default), Mode B attempts a wildcard-wrap repair if the server 400s on a Name=value clause with no wildcards. Set False for exact-match queries that should NOT be relaxed."New value: +"Allow the wildcard-wrap repair on 400 (default). Set False for exact-match queries that must not be relaxed."

changedInput schema / properties / lf_query / examples

Previous value: -[
-  "{LF:Name=\"*Acme*\"}",
-  "{[Invoice]:[Vendor]=\"Acme*\"}"
-]New value: +[
+  "{LF:Name=\"*Acme*\"}",
+  "{LF:Basic~=\"unpaid balance\",option=\"D\"}",
+  "{[Invoice]:[Vendor]=\"Acme*\"}"
+]

changedInput schema / properties / max_results / description

Previous value: -"Page size. Clamped to LF_MAX_PAGE_SIZE (default 100) — some self-hosted SimpleSearches implementations 400 on larger $top."New value: +"Page size, clamped to LF_MAX_PAGE_SIZE (default 100)."

changedInput schema / properties / question / description

Previous value: -"The user's natural-language search question. Used by Mode A to extract keywords for candidate queries and surfaced in Mode B responses for correlation."New value: +"The user's natural-language search question."

changedInput schema / properties / question / examples

Previous value: -[
-  "find the latest invoice from Acme",
-  "what onboarding docs do we have for Smith?"
-]New value: +[
+  "find the latest invoice from Acme"
+]

First observedv2.1.0Jun 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided the description carries the full burden, and it does so richly: it documents Mode A's return shape (grammar, discovered_templates, up to 3 candidate_queries), Mode B's automatic repair behavior on HTTP 400 (escaping inner quotes, wildcard-wrapping bare Name=), the error path returning attempts entries, and the pagination_unknown flag semantics. This is exactly the behavioral detail an agent needs before invoking.

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?

Front-loaded with the two-mode framing, then usage routing, then per-mode details under bolded headers. Despite covering a lot, every sentence carries distinct information and nothing is padded.

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 complex two-mode tool with no annotations, the description supplies the mode contract, retry semantics, and error/result markers, and an output schema exists so return values need not be re-explained. 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.

Parameters3/5

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

Schema description coverage is 100% and the schema already documents each parameter with defaults and examples, so the baseline is 3. The description reinforces mode meanings (lf_query omitted vs given) but adds little syntax or format detail beyond what the schema's parameter descriptions already provide.

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 line states a specific verb+resource ('Two-mode search') and immediately defines both modes. It further distinguishes itself from siblings by naming search_content and search_entries and the conditions that route to them, so an agent can tell it apart 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?

Explicit when-to-use ('when you need to author a Laserfiche query and don't know the server's templates or field names') plus explicit alternatives ('For content questions, prefer search_content; for a query you can already write, search_entries'). Both the trigger and the exclusions are spelled out.

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