laserfiche-mcp

laserfiche_template_definition_list

List template definitions in a Laserfiche repository, including ID, name, and field count. Filter by exact template name or get a count/names summary. Provides pagination for large repositories.

Instructions

List template definitions in the repository.

Discover template names (each item: id, name, fieldCount); pass template_name to filter to one. Does NOT enumerate a template's fields — use get_template_fields for that. On failure returns {"mode": "error", "error": <slug>}.

Input Schema

TableJSON Schema

Name	Required	Description
`skip`	No	0-indexed offset for pagination through large repositories.
`max_results`	No	Page size (default 25, capped by LF_MAX_RESULTS_CEILING).
`summary_only`	No	When True, return only {count, names} instead of the full listing.
`template_name`	No	Exact template name to filter to (case-sensitive on most builds).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.3.0Sep 21, 2026

changedInput schema / properties / summary_only / description

Previous value: -"When True, return only {count, names} instead of the full OData listing — useful for 'what's available?' lookups that would otherwise return 30-50 KB of definition payload."New value: +"When True, return only {count, names} instead of the full listing."

changedInput schema / properties / template_name / description

Previous value: -"If set, return only the template with this exact name. Case-sensitive on most builds."New value: +"Exact template name to filter to (case-sensitive on most builds)."

removedInput schema / properties / template_name / examples

Removed value: -[
-  "Personnel Document",
-  "Loan Application"
-]

First observedv2.1.0Jun 22, 2026

TDQS

A4/5.0

Behavior3/5

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

No annotations are present, so the description carries the behavioral burden. It does disclose the failure return shape and a behavioral boundary (no field enumeration), but it omits other useful behavioral context such as auth/permission needs, rate limits, or side effects. The read-only nature is only implied by the word 'List'.

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 compact and front-loaded, with the purpose stated first and each subsequent sentence earning its place. The boundary, filter behavior, and failure-mode note are all relevant and formatted with backticks for scannability. There is no filler or redundancy.

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?

With an output schema and fully documented parameters, the description is largely complete: it covers the output item shape, filtering behavior, the key limitation, and the failure format. The only notable gap is the misnamed alternative tool, which prevents fully reliable routing; otherwise this would merit a 5.

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%, so the baseline is 3. The description adds only a minor semantic ('filter to one') beyond the schema's existing parameter descriptions. It does not clarify skip, max_results, or summary_only beyond what the input schema already documents.

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 verb and resource ('List template definitions') and immediately distinguishes itself from field enumeration by noting it does NOT enumerate fields. The mention of item fields (id, name, fieldCount) and template_name filtering further clarifies the tool's exact scope. It is clearly differentiated from laserfiche_template_field_list and other list tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit when-not instruction: 'Does NOT enumerate a template's fields — use get_template_fields for that.' However, the named alternative does not match any sibling tool exactly (the correct sibling appears to be laserfiche_template_field_list), which weakens the routing guidance. It provides no guidance on choosing among other list tools, but the core exclusion is explicit.

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