Skip to main content
Glama
SamuelSHernandez

laserfiche-mcp

by SamuelSHernandez
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

laserfiche_template_field_list

Retrieve a template's fields with full metadata in one call, providing the required structure for assign_template and eliminating multi-step lookups.

Instructions

Return one template's fields with full metadata, in a single call.

Use before assign_template to construct its fields argument — replaces the list-templates + list-fields + cross-reference chain.

Returns {"template_name", "template_id", "field_count", "fields"}; each field has name, field_type, is_required, is_multi_value, list_values, default_value, constraint. On failure returns {"mode": "error", "error": <slug>} — invalid_template_name includes the list of valid names.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
required_onlyNoReturn only fields where is_required is true.
template_nameYesExact template name (case-sensitive on most builds); discover names with list_template_definitions.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.3.0
    • changedInput schema / properties / required_only / description
      Previous value: -"When True, return only fields where is_required is true — useful for 'what's the minimum I have to supply?' workflows."New value: +"Return only fields where is_required is true."
    • changedInput schema / properties / template_name / description
      Previous value: -"Exact template name (case-sensitive on most builds). Use list_template_definitions to discover available names."New value: +"Exact template name (case-sensitive on most builds); discover names with list_template_definitions."
    • removedInput schema / properties / template_name / examples
      Removed value: -[
-  "Personnel Document",
-  "Loan Application",
-  "Invoice"
-]
  2. First observedv2.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Although no annotations are provided, the description discloses the return structure and error handling. It mentions that on failure it returns an error mode with a slug and that 'invalid_template_name' includes a list of valid names. This provides useful behavioral context beyond the schema, such as the error format and the hint for resolving invalid names. However, it doesn't explicitly state if the operation is read-only or has side effects, but as a read operation, the error handling is a key transparency point.

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 concise and well-structured. It starts with the primary action, then provides usage context, then details the return structure and error handling in a clear list. Every sentence serves a purpose, and the key information is front-loaded.

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?

Given the tool's moderate complexity, the description covers the essential aspects: the single required parameter, the optional filter, the return structure, and error cases. The output schema is present, so return format details are already encoded. The description is complete for an agent to use the tool correctly without additional context.

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 provides descriptions for both parameters, covering their meaning (exact name, case-sensitivity, and how to discover names) and the optional flag. The description adds context on how the 'required_only' parameter affects the output (filters fields), which is implied in the schema but clarified here. Since schema coverage is 100%, the description adds marginal value but is still helpful.

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 ('Return'), a specific resource ('one template's fields'), and the scope ('with full metadata'). It clearly distinguishes itself from related list tools by focusing on a single template's fields, and it references a sibling (assign_template) to clarify its purpose in the workflow.

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 states when to use this tool: 'Use before assign_template to construct its fields argument.' It also explains that it replaces a more complex chain (list-templates + list-fields + cross-reference), providing clear guidance on the optimal usage context compared to alternatives.

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