search_natural
Search Laserfiche using natural language: get guidance to build a valid query, then execute with automatic repair of common syntax errors.
Instructions
Two-mode search: guidance first, then execution with automatic repair.
Most Laserfiche servers reject malformed query syntax with a generic HTTP 400. This tool gives the host LLM a structured way to author a working query without trial-and-error against the user.
Mode A — lf_query omitted
Returns mode="guidance" with:
* grammar — the Laserfiche search syntax reference this server
understands, with examples.
* discovered_templates — template names and field names sampled
from folder_path (or the repository root). Use these to
author template-field queries like
{[Personnel]:[Last Name]="Smith"}.
* candidate_queries — up to 3 starter queries built from the
question's keywords. Pick one or refine it, then call again with
lf_query.
* follow_up — the exact follow-up call shape.
Mode B — lf_query provided
Executes the query and returns mode="results" (or
mode="error" with structured detail). On HTTP 400, up to two
automatic repairs are attempted:
1. Escape unescaped ``"`` characters inside ``="..."`` value spans.
2. Wrap ``Name="value"`` values in ``*`` wildcards (only when
``fuzzy=True`` and the value has no wildcard).
Each attempt is recorded in ``attempts`` on the error response.Pagination
max_results is clamped to LF_MAX_PAGE_SIZE (default 100).
Some self-hosted SimpleSearches implementations 400 on larger
$top values, so the cap is lower than the list-folder ceiling.
When next_link is null but the result count hit the effective
cap, pagination_unknown=true is surfaced — there may be more
results, the server just didn't say.
What this tool does NOT do It does not silently fall back to folder traversal. If both repairs still 400, you get a structured error so the user knows search failed and the host LLM can author a fresh query.
On failure
Mode B returns {mode: "error", attempts: [...]} with the full
repair history visible — each attempt records the query, the repair
tag applied, the HTTP status, and the server's error body, enough
context for the LLM to write a different query. Other failures
(auth, rate limit, network) come back via the generic error
contract; see docs/error-contract.md.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | 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. | |
| lf_query | No | Laserfiche query to execute (Mode B). Omit to get guidance (Mode A): grammar reference, sampled templates, candidate queries to refine. | |
| 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) — some self-hosted SimpleSearches implementations 400 on larger $top. | |
| fuzzy | No | 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. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||