Skip to main content
Glama
SamuelSHernandez

laserfiche-mcp

by SamuelSHernandez
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

laserfiche_entry_search_natural

Search Laserfiche entries by asking a natural-language question. Get query guidance or run the query with automatic repair for errors.

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"; pagination_unknown=true means the server hit the cap without saying whether more exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fuzzyNoAllow the wildcard-wrap repair on 400 (default). Set False for exact-match queries that must not be relaxed.
lf_queryNoLaserfiche query to execute (Mode B). Omit to get guidance (Mode A): grammar reference, sampled templates, candidate queries to refine.
questionYesThe user's natural-language search question.
folder_pathNoBackslash-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_resultsNoPage size, clamped to LF_MAX_PAGE_SIZE (default 100).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.3.0
    • 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"
+]
  2. First observedv2.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It reveals the two modes, the auto-repair behavior on HTTP 400 (up to two repairs), the retry logic, and the `mode="error"` response containing every attempt. It also discloses the `pagination_unknown=true` flag for server caps. It doesn't explicitly state read-only status or auth requirements, but for a search tool these are largely implied and the disclosed repair/error behaviors are the critical transparency points.

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?

The description is detailed but efficiently structured: a one-line summary, a context sentence with sibling routing, then clear Mode A and Mode B sections with bold headers. Every sentence earns its place—no fluff or repetition. The use of bullets and explicit mode labels makes the two-mode behavior easy to parse quickly.

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?

Given the tool's complexity (two modes, auto-repair, pagination uncertainty, folder scoping, and sibling relationships), the description is nearly complete. It covers mode behavior, repair reasons, error output shape, and the `pagination_unknown` edge case. The output schema exists, so return-value details don't need to be spelled out. Missing only minor edge-case details like non-400 failures, but the description provides strong coverage for an agent to call and interpret the tool correctly.

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?

The schema already documents all five parameters with 100% coverage, so the baseline is 3. The description adds meaningful interaction semantics beyond the schema: how omitting vs. providing `lf_query` switches modes, how `fuzzy` controls the wildcard-wrap repair, and how `folder_path` behaves differently in Mode A vs. Mode B. It also explains `max_results` clamping to `LF_MAX_PAGE_SIZE`, reinforcing the schema. This justifies a point above baseline, though not a 5 since some details like the exact repair mechanics are description-schema duplicative.

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 description states a specific two-mode search tool with a clear verb and resource: 'Two-mode search: get query-authoring guidance, then execute with auto-repair.' It also distinguishes itself from siblings by explicitly naming when to prefer `search_content` for content questions and `search_entries` for queries the user can already write. This makes the tool's purpose and niche unambiguous.

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?

The description explicitly tells the agent when to use this tool: when you need to author a Laserfiche query and don't know the server's templates or field names. It also gives clear exclusions and alternatives: 'For content questions, prefer `search_content`; for a query you can already write, `search_entries`.' Additionally, Mode A vs. Mode B usage is spelled out, so the agent knows exactly when to omit or provide `lf_query`.

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

Deploy Server

Other Tools