laserfiche-mcp

laserfiche_link_definition_list

List entry-link type definitions to obtain linkTypeId for setting links. Provides sourceLabel and targetLabel for directed link types.

Instructions

List the entry-link type definitions on this repository.

Use before set_links — links need a linkTypeId from here. Each item has linkTypeId, sourceLabel, targetLabel (link types are directed). 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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field 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."

First observedv2.1.0Jun 22, 2026

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the item fields (linkTypeId, sourceLabel, targetLabel), notes that link types are directed, and gives the failure response shape. This is strong behavioral context for a read-only listing operation.

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?

Three short sentences with no filler: purpose, usage context, and output/failure details. Information is front-loaded and every sentence earns its place.

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 output schema exists and all parameters are fully described in the schema, the description supplies the missing context: when to use it, what fields the results contain, that link types are directed, and the error format. An agent has everything needed to invoke this correctly.

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?

The input schema covers all three parameters with clear descriptions and defaults, so the description does not need to add much. It does not meaningfully elaborate on skip, max_results, or summary_only beyond the schema, which meets the baseline for 100% schema coverage.

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: it lists entry-link type definitions on the repository. This clearly differentiates it from sibling definition-list tools like laserfiche_field_definition_list and laserfiche_tag_definition_list.

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?

It explicitly says to use this tool before set_links because a linkTypeId is needed from here. It does not enumerate when-not-to-use or compare against all alternatives, but the usage context is clear and actionable.

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