laserfiche-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.2.0
Disambiguation2/5
Many tools have near-identical duplicates with and without the 'laserfiche_' prefix (e.g., get_document_edoc and laserfiche_document_get_edoc), causing confusion. Additionally, async task tools overlap (get_task_status, wait_for_task, task_wait_or_poll) with unclear boundaries.
Naming Consistency2/5
Naming is inconsistent, mixing verb_noun (get_entry), noun_verb (field_values_get), and prefixed variants (laserfiche_entry_get). The prefix is applied irregularly, and some tools have both forms with identical descriptions.
Tool Count3/5
At 38 tools, the count is inflated by duplicates; the effective distinct set is about 19. While the domain warrants multiple tools, the duplication makes the surface feel bloated and harder to navigate.
Completeness2/5
The server covers many read and search operations but lacks critical write tools like create_entry, update_entry, delete_entry, assign_template, or set_links. Async operations are referenced but not exposed, leaving significant gaps for common workflows.
Average 4.7/5 across 38 of 38 tools scored. Lowest: 4.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on July 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully describes behavior: it resolves the path, returns an EntryDetail, and on failure returns an error object with specific slugs. It also notes that forward slashes are accepted. This is sufficient for a read-only lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first paragraph gives purpose, second explains usage, third covers failure. It is concise without being terse, though the failure paragraph could be slightly reduced. Front-loaded with core purpose.
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 simplicity (one parameter, no nested objects), the description covers return values (EntryDetail shape), failure modes with common slugs, and usage context. No output schema is present, but the description provides enough information. It is complete for a straightforward path resolution tool.
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 usage examples and context but does not significantly expand on the schema's explanation (e.g., case-insensitivity is in the schema but not in the description). The parameter semantics are adequately covered by the schema.
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 uses the specific verb 'resolve' targeting a 'backslash-delimited Laserfiche path' to its entry, clearly distinguishing it from sibling tools like 'get_entry' (which uses IDs) and search tools. It explicitly states when to use it: when the user refers to a location by path rather than ID.
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 explains when to use the tool (user pastes a path, or path authored from known structure) and what to do with the result (feed ID into other tools). It does not explicitly state when not to use it, but the usage context is clear and differentiates it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: it handles endpoint failure by returning a fallback instead of raising an error, and specifies that it never returns mode:error. This is comprehensive for a zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, followed by usage guidance and detailed return shapes. It is concise but includes necessary details about fallback.
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 no parameters and the presence of an output schema, the description thoroughly explains both success and failure return shapes, including the fallback mode. It covers edge cases and is complete for effective tool use.
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?
There are no parameters, so baseline is 4. The description adds no parameter info, which is appropriate as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists repositories the account can reach. It has a specific verb and resource, but does not explicitly distinguish from sibling list tools like list_folder or search_entries, though it is unique in purpose.
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 explains when to use the tool (confirming repository, discovering alternates) and provides guidance on endpoint variability and fallback behavior. It does not list alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 failure modes (error slugs like 'not_found', 'auth_failed') and the output shape, which provides good behavioral context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, usage, arguments, returns, and failures. It is front-loaded with the main purpose and concise enough. Minor redundancy with schema but acceptable.
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 simplicity (single parameter, output schema defined), the description covers all necessary aspects: purpose, usage guidance, parameter details, return value shape, and failure modes. No critical gaps.
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?
Schema coverage is 100% with a thorough description and examples. The tool description adds value by repeating the parameter info in a readable form, noting that forward slashes are accepted, and providing an explicit example. It does not add much beyond the schema but is 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 clearly states the tool resolves a backslash-delimited Laserfiche path to its entry, using specific verbs. It distinguishes from siblings like 'get_entry' (which uses an ID) by explicitly referencing path-based resolution.
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 explicitly says when to use: when the user refers to a location by its path, such as from the web client. It also explains how the returned id feeds into other tools, but it does not mention when *not* to use it or provide explicit alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It fully describes return format under 'values' key, each field item structure, empty/unset field handling (omitted by Repository API), and failure modes with error slugs. This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with separate sections for purpose, usage, args, returns, and errors. Each sentence adds value, though slightly verbose in the returns section. No fluff.
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 a single parameter and presence of output schema, description covers all necessary context: when to use, output structure details, empty behavior, and failure modes. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for the only parameter 'entry_id'. Description adds only 'Integer entry ID' which adds minimal meaning. With no schema description, this is insufficient; should provide more context like expected range or source of entry ID.
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?
Description states 'Read the template field values currently on an entry' with specific verb and resource. Distinguishes from sibling tools like 'get_entry' by clarifying that 'For the entry's own properties (name, type, path), use get_entry instead.'
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?
Explicitly says 'Use after you have an entry ID and need the metadata fields the user is asking about' with concrete query examples. Also provides negative guidance: 'For the entry's own properties, use get_entry instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes the behavior: returns OData listing with value, each item has linkTypeId, sourceLabel, targetLabel, linkTypeDescription; mentions default link types and error format. It discloses pagination behavior and summary_only mode, adding useful context beyond a simple 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 front-loaded with purpose, followed by usage context, parameter docs, return format, and error handling. Every sentence adds value with no redundancy. It is efficiently written.
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 no annotations and an output schema (not fully detailed), the description provides sufficient context about the operation: list, pagination, return structure, and error handling. It could mention that it's read-only, but that is implied.
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?
Schema coverage is 100%, so the schema already provides parameter info. The description adds value by explaining the effect of summary_only (avoids large payload) and clarifies defaults and pagination offset. This goes beyond the schema's descriptions.
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 clearly states the tool lists entry-link type definitions with a specific verb ('List') and resource ('entry-link type definitions'). It distinguishes from sibling list tools (e.g., field, tag, template definitions) by focusing on link types.
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 explicitly says 'Use before calling set_links — you need a linkTypeId from this listing to construct a valid link.' This provides clear when-to-use guidance. It does not explicitly list when not to use, but the context and sibling names make the purpose distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description mentions it retrieves metadata (read-only behavior), specifies the return fields, and describes error response format. It does not explicitly mention side effects or authentication, but the read-only nature is clear.
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?
Well-structured with a clear first sentence, then usage context, explicit exclusions, and a concise args/returns section. Every sentence adds value, and it is appropriately sized for the tool's simplicity.
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 a single parameter, no annotations, but presence of output schema, the description covers purpose, usage, parameter, return fields, and error conditions comprehensively. No gaps remain.
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?
Despite 0% schema description coverage, the description mentions the sole parameter 'entry_id' as 'Integer entry ID.' This adds minimal information over the schema type definition; however, since there is only one simple parameter, it is adequate.
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?
Clearly states 'Fetch metadata for a single entry by ID' with explicit verb and resource. Distinguishes from sibling tools by noting it does not return field values (call get_field_values) or document content (call get_document_edoc).
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?
Explicitly states when to use: after obtaining an entry ID from search, list_folder, or get_entry_by_path. Also provides explicit guidance on what not to use it for and which alternative tools to call instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes response structure (types, multi-value, allowed values), pagination parameters, summary_only behavior, and error format. No annotations provided, but description compensates well.
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?
Front-loaded with summary, organized into paragraphs and bullet points, no wasted words. Efficiently covers all necessary information.
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?
Thoroughly covers pagination, summary mode, output fields, and error response. Given output schema existence and parameter count, this is complete.
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?
Schema has 100% description coverage; description adds value by explaining default page size, capping, and the purpose of summary_only (avoiding large payloads).
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?
Clearly states 'List every field definition in the repository' with verb and resource. Distinguishes from sibling tools like get_template_fields by mentioning combination with list_template_definitions.
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?
Explicitly says 'Use before authoring a field-based search query or preparing a field update' and suggests combining with list_template_definitions. No explicit when-not-to-use but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Clearly states it returns metadata only and not field values or content. Describes error slugs. Minor lack of mention of auth requirements, but acceptable for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections, bullet points, and explicit 'does NOT' statements. Slightly verbose but every sentence adds value.
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 output schema exists, description provides enough context: lists return fields, covers error handling, and explains what the tool does not do. Complete for a single-parameter metadata fetch tool.
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?
Only one parameter entry_id. Description adds context: 'Integer entry ID' and where to obtain it (from search, list_folder, etc.), which adds value beyond schema's type and required declaration.
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?
Description clearly states 'Fetch metadata for a single entry by ID' with specific verb and resource. Distinguishes from siblings by noting alternative tools for field values and document content.
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?
Explicitly states when to use (once you have an entry ID from specific tools) and what it does NOT return, with clear pointers to alternatives (get_field_values, get_document_edoc). Includes return format and error handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: return structure, field metadata details, failure slugs (invalid_template_name, server_error), and case-sensitivity. It meets the full burden for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args, Returns, and On failure sections. Each sentence adds value, though slightly verbose. Efficient for the information density.
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 role in a broader workflow and the presence of an output schema, the description is thorough: explains return format, error handling, usage context, and links to sibling tools. No gaps.
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?
Schema coverage is 100%, so baseline 3. The description adds extra context beyond the schema: clarifies case-sensitivity for template_name, suggests using list_template_definitions, and explains the required_only parameter's utility. This justifies a 4.
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 clearly states it returns fields belonging to a single template with full field metadata. It distinguishes itself from siblings like list_template_definitions and list_field_definitions by solving the cross-referencing gap.
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?
Provides explicit workflow guidance: use this BEFORE assign_template to construct the fields argument. Also mentions using list_template_definitions to discover names. Lacks explicit when-not-to-use instructions but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: two execution paths, return payload (same as underlying tools), added timed_out field for wait variant, and failure shapes. No contradictions or hidden traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and bullet points, about 10 sentences all adding value. Slightly wordy but not excessive. Each section 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 an output schema exists (context indicates true), the description explains return payload and failure handling. It covers all parameter behaviors, modes, and edge cases. No missing context for agent decision-making.
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?
Schema coverage is 100%, baseline 3. The description adds semantic value: operation_token origin (async tools list), timeout_seconds behavior and client-tolerance bound, poll_interval_seconds lower bound and ignored condition. Exceeds schema info.
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 clearly states the tool checks or waits on an async operation, distinguishing two modes based on timeout_seconds. It explicitly mentions wrapping two underlying tools, providing specific verb-resource combinations and differentiation from siblings.
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 clear guidance on when to use timeout_seconds=0 (single-poll) vs >0 (blocking wait), and mentions polling loops. It does not explicitly list alternatives or when-not-to-use, but the context is sufficient. Siblings include get_task_status and wait_for_task, but this tool is a composite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: blocking, polling interval, timeout handling, return payload with timed_out flag, and error scenarios with common slugs like not_found and auth_failed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line followed by details, Args, Returns, and On failure sections. It is slightly verbose but each sentence adds value and 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 output schema exists, the description adequately covers the tool's behavior, return value (same as get_task_status plus timed_out), and error handling. All parameters are explained with use-case guidance, making it complete for agent invocation.
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 covers all parameters with descriptions and examples, and the description adds practical guidance (e.g., higher timeout for large deletes) and bounds clarification for poll_interval, going beyond the schema alone.
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 clearly states the tool blocks until an async operation reaches a terminal state and explicitly distinguishes it from manual polling using get_task_status, providing a specific verb-resource pair with clear scope.
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 recommends this tool over manual polling with get_task_status and provides context for increasing timeout for large operations, but does not explicitly differentiate from other sibling wait tools like wait_for_task or task_wait_or_poll.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the return format (OData listing with value, fields), behavior of summary_only parameter (return {count, names}), and failure mode (error object). This is comprehensive for a read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for purpose, usage, args, returns, and failure. Front-loaded with purpose. Could be slightly more concise but is efficient and clear.
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 simplicity (3 params, no required, with output schema), the description covers all necessary aspects: usage, pagination, summary mode, return fields, and failure. It even includes common examples of link types, making it highly complete.
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?
Schema coverage is 100% with descriptions, but the description adds value by explaining defaults (max_results default 25, skip default 0) and the pragmatic use of summary_only to avoid heavy payloads. This contextual information goes beyond what the schema provides.
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 clearly states 'List the entry-link type definitions available on this repository,' providing a specific verb and resource. It distinguishes itself from sibling listing tools by specifying 'entry-link type definitions' and further explains directed link types with source and target labels.
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?
Explicitly states 'Use before calling set_links — you need a linkTypeId from this listing to construct a valid link,' providing clear context for when to use. Does not explicitly exclude alternatives, but the direct reference to set_links makes the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does so by explaining pagination (skip, max_results), the summary_only mode, error format, and that the response does not include field definitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, parameter documentation, and return/failure details. It is detailed but not excessively long, though some redundancy exists (e.g., repeating max_results default).
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 has 4 parameters, no required ones, and an output schema, the description covers all necessary aspects: purpose, parameter usage, response shape, failure mode, and relationship to other tools like list_field_definitions.
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?
Schema coverage is 100%, baseline is 3. The description adds value by elaborating on each parameter: template_name's server-side filtering and case-sensitivity, max_results cap, skip offset, and summary_only's use case.
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 clearly states 'List template definitions in the repository' and positions the tool as a discovery step before calling assign_template. It distinguishes from siblings like list_field_definitions by explaining what the tool does not return (fields).
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 explicitly tells when to use ('discover which templates exist before calling assign_template') and for each parameter explains its effect. It does not explicitly state when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states it wraps `search_entries` with LF:Name and LookIn clauses, describes error returns ('mode: error'), and notes endpoint fragility and fallback advice. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (Args, Returns, On failure). Front-loaded with purpose. Each sentence adds value, though slightly verbose for those familiar with the domain. Still, no wasted words.
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?
Covers purpose, usage, all parameters with details, error handling, and fallback advice. Output schema exists but description references return shape. For a search tool with moderate complexity, this is complete.
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?
Schema coverage is 100%, baseline 3. Description adds significant value beyond schema: explains wildcard behavior with examples, folder path format, default max_results. This justifies a 4.
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 clearly states it finds entries by name pattern with optional folder scoping. It contrasts with sibling `search_entries` by explaining it wraps that with a specific clause, and mentions fallback to `search_natural`. The verb 'Find' and resource 'entries' are specific.
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?
Specifies when to use: 'when searching by name and full query syntax is overkill'. Also advises fallback to `search_natural` on repeated errors. Does not explicitly list when not to use, but provides a clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It thoroughly discloses behavior: three modes with detailed return info, size cap handling, error slugs for various cases (e.g., `not_found`, `auth_failed`), and details on text extraction limitations (OCR not attempted, encrypted PDFs).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for modes and parameter details. It is fairly long but each sentence adds value. Slightly verbose in explaining modes, but overall efficient.
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 complexity (4 params, 3 modes, output schema), the description is very complete. It explains return shapes per mode, error responses with common slugs, and size cap behavior. The output schema exists but the description adds essential context on failure modes and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant detail beyond the schema. For example, it explains the mode enum in depth (including default and behavior for each), the `max_bytes` override, `text_char_limit` truncation signaling, and the `entry_id` requirement.
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 clearly states 'Download or inspect a document's raw electronic file (edoc).' It also distinguishes itself from the sibling tool `get_document_text` by noting that `get_document_text` has no endpoint on v1 servers, making the purpose specific and differentiated.
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 provides clear context: it is the recommended path for reading content on v1 servers, and explains the three modes with trade-offs. It does not explicitly state when not to use, but the alternatives are implied through the mode explanations and the mention of `get_document_text`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully details the return format, including the structure of each field descriptor and behavior for empty/unset fields. It also covers failure modes with common error slugs. However, it doesn't mention authorization or rate limits, but as a read operation with no annotations, the provided information is still substantial.
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: a one-line purpose, followed by usage guidance, examples, parameter definition, return format details, and error information. Every sentence adds value without redundancy.
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 simplicity (one parameter, output schema detailed in description), the description provides complete context. It covers when to use, what to expect in return, and error handling. The distinction from get_entry makes it contextually complete among siblings.
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 only parameter 'entry_id' is explained in the Args section as 'Integer entry ID', which combined with the context of needing an entry ID makes its purpose clear. While the schema itself has no description (0% coverage), the description compensates adequately, though it could be more explicit about what the ID refers to.
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 clearly states the tool reads template field values from an entry, with a specific verb 'Read' and resource 'template field values'. It distinguishes from sibling tool 'get_entry' by noting that for entry properties (name, type, path) one should use get_entry instead.
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 when to use the tool: after having an entry ID and needing metadata fields. It gives example questions and directly advises against using it for entry properties, directing to get_entry instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It thoroughly explains behavioral traits: mode-specific handling, size cap enforcement, truncation signaling, error slugs (not_found, auth_failed), and that OCR is not attempted. It also details response shapes and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Args, Returns, and On failure, using bullet points for modes. It is front-loaded with the purpose. While somewhat lengthy, every sentence adds value. Minor redundancy in error explanation could be trimmed.
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 complexity (4 parameters, 3 modes, output schema present), the description is exceptionally complete. It covers all modes, error cases, edge cases (encrypted PDFs, unsupported types), and explains why get_document_text is unavailable on v1. It leaves no ambiguity for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context beyond schema defaults and descriptions. It explains per-mode applicability of max_bytes and text_char_limit, the default cap of 25 MB, and how bytes mode refuses oversized files. It also clarifies that text_char_limit truncation is signaled via a field, not a marker.
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 clearly states 'Download or inspect a document's raw electronic file (edoc)', differentiating from sibling tools by noting that 'get_document_text has no endpoint to call there' on v1 servers. It explicitly describes three modes and their purposes.
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 advises using 'info' as a first probe, and distinguishes between modes for different needs. It implicitly contrasts with get_document_text by explaining when this tool is the alternative. However, it does not explicitly list all alternative tools or provide a when-not-to-use scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses that the tool wraps search_entries, uses the same fragile endpoint, and describes the return shape and error format. It also mentions case-insensitivity and wildcards. It could add more about rate limits or pagination details, but the existing transparency is quite good.
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 well-structured with clear sections (Args, Returns, On failure). It is concise, front-loads the purpose, and every sentence adds value. No wasted words.
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 has 3 parameters and an output schema (not shown but mentioned), the description covers purpose, usage, parameter details, return shape, error handling, and alternatives. It is complete and leaves no significant gaps for an agent to use 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?
Schema coverage is 100% with good descriptions, but the description adds extra value with detailed wildcard examples for name_pattern, path format for in_folder_path, and a note about max_results default being capped by LF_MAX_RESULTS_CEILING. These examples enhance understanding beyond the schema alone.
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 clearly states the tool finds entries by file/folder name pattern and positions it as a convenience wrapper over search_entries. It distinguishes itself from sibling tools like search_entries and search_natural by specifically targeting name-based searches without full query syntax.
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 says 'Use when the user is searching by name and the full Laserfiche query syntax is overkill.' It also provides a fallback strategy: 'fall back to search_natural if you get repeated server_error results.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral transparency. It covers two operational modes, automatic repair attempts on HTTP 400 (with details on repair steps), pagination behavior (max_results clamped, potential 400s on large $top, 'pagination_unknown' flag), and structured error responses. It also explicitly states what the tool does NOT do (no silent fallback).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear headings (Mode A, Mode B, Pagination, What this tool does NOT do, On failure). It is front-loaded with the core purpose. Some redundancy exists (e.g., error handling mentioned twice), but overall the structure aids readability given the complexity.
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 complexity (two modes, automatic repair, pagination nuances, error handling) and the presence of an output schema, the description covers all necessary context: what the tool does, when to use each mode, constraints (clamping, 400 risks), failure behavior, and explicit exclusions. No missing aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have descriptions in the schema (100% coverage). The description adds extra meaning beyond the schema: for max_results it explains why it's clamped and the risk of 400s; for lf_query it explains mode semantics; for fuzzy it details the wildcard repair behavior; for folder_path it explains usage in both modes. This additional context is valuable.
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 clearly states the tool does two-mode search: guidance (Mode A when lf_query omitted) and execution with automatic repair (Mode B when lf_query provided). It explicitly distinguishes itself by stating 'What this tool does NOT do' (no silent fallback), helping to differentiate from sibling tools like laserfiche_entry_search.
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 explains when to use Mode A (to get guidance, grammar, templates, candidate queries) versus Mode B (to execute a query). It also describes the automatic repair behavior and pagination. However, it does not explicitly compare against sibling tools like laserfiche_entry_search or search_entries, missing an opportunity to guide users on alternative choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully carries burden. Discloses server rejection of undefined tags, empty value normal for many repos, pagination behavior, and failure mode. Could add more on rate limits or auth requirements, but overall transparent.
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?
Well-structured with Args and Returns sections. Every sentence provides essential information. No redundant or filler text. Efficient for agent consumption.
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?
Output schema exists, so return values are expected there. Description still clarifies the raw OData structure, fields, failure mode, and common edge case (empty repos). Complete for agent decision-making.
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?
Schema coverage is 100% with descriptions, so baseline is 3. Description adds value beyond schema: mentions LF_MAX_RESULTS_CEILING cap, explains summary_only as useful for 'what's available?' lookups, and clarifies pagination offset meaning.
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?
Clearly states 'List every tag definition in the repository' with specific verb and resource. Distinguishes from sibling tools like set_tags/merge_tags and other list tools through context.
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?
Explicitly advises to use before set_tags/merge_tags to confirm tag existence, explains server rejection of undefined tags, and notes that tags are a flat namespace distinct from template fields. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the behavior: it is a read-only status check, details the return payload structure, and explains failure modes with common error slugs like 'not_found' and 'auth_failed'.
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?
Description is front-loaded with the core purpose, followed by context, usage guidance, and detailed returns/errors. Every sentence is informative and well-organized without redundancy.
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 simplicity (one parameter) and the presence of an output schema, the description covers all necessary aspects: purpose, usage, parameter, return values including fields and possible errors, and differentiation from sibling tools.
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 coverage is 100% and the schema already includes a description and examples for the single parameter 'operation_token'. The description adds minimal additional context (e.g., mentioning which tools return the token), but the schema carries the bulk of the semantics.
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?
Description clearly states 'Look up the status of an async operation by its token', specifying the verb (look up), resource (status of async operation), and mechanism (by token). It also distinguishes from the sibling 'wait_for_task' by explaining the difference in semantics.
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?
Explicitly provides guidance on when to use this tool versus alternatives: 'For "wait until done" semantics, use wait_for_task instead so you don't have to write a polling loop.' Also lists the originating async tools that return the token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: it explains return format (OData listing with specific fields), pagination (max_results, skip), server-side filtering, case sensitivity, summary mode, error format, and that fields are not included. This is comprehensive behavioral disclosure.
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 well-structured with clear sections (use case, parameter descriptions, return format, error format). Every sentence adds value, and it is appropriately sized for the tool's complexity. No wasted words.
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 4 parameters, an output schema, and no annotations, the description covers all critical aspects: purpose, usage, all parameters with added context, return data structure, error handling, and links to related tools. It is fully self-contained and allows correct invocation.
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?
Schema coverage is 100%, but the description adds value beyond schema: for summary_only it explains the payload size benefit, and for template_name it clarifies case-sensitivity and server-side filtering. The description enriches parameter understanding without redundancy.
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 clearly states 'List template definitions in the repository.' It differentiates from sibling tools like list_field_definitions by noting it does not return fields, and explicitly connects to assign_template. The purpose is specific and actionable.
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 explicitly recommends using this tool 'before calling assign_template' and explains the summary_only mode for 'what's available?' lookups. It also describes the error format. It does not explicitly state when not to use, but the context is strong enough for an agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers read-only nature, return format (OData list with id, name, isSecurityTag), pagination, and error response. Could mention rate limits or auth but sufficient.
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?
Well-structured: purpose, usage guidance, parameter explanations, return format, error handling. Every sentence adds value, no redundancy.
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 3 optional params and an output schema, the description covers all necessary context: when to use, pagination, summary_only, return format, error mode, and normal empty result.
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?
Schema coverage is 100%, baseline 3. Description adds extra context for summary_only (payload size) and clarifies default/cap for max_results, exceeding schema details.
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?
Clearly states 'List every tag definition in the repository' and distinguishes from sibling tools (e.g., set_tags, merge_tags, other list definitions) by specifying tag definitions and clarifying the namespace.
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?
Explicitly advises using before set_tags/merge_tags to verify tag existence, noting server rejection. Also explains when summary_only is useful and that empty list is normal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully bears the burden. It thoroughly explains blocking, polling, timeout behavior (returns timed_out=true on timeout), terminal states (Completed, Failed, Canceled), and error handling with specific error slugs and failure modes.
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, front-loaded with the core action, and well-structured with sections for Args, Returns, and On failure. Every sentence serves a purpose without redundancy.
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 no annotations but a known output schema, the description covers return payload similarity to get_task_status plus the added timed_out field, error responses, and common error slugs. It leaves no obvious gaps for this polling tool.
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?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by clarifying that operation_token is 'server-scoped' and that timeout_seconds should be increased for large operations, and poll_interval_seconds is bounded below at 0.1s.
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 opens with a clear, specific verb-resource statement: 'Block until an async operation reaches a terminal state.' It distinguishes itself from manual polling (get_task_status) and other siblings by explicitly stating it blocks and handles polling.
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 states 'Preferred over manual polling with ``get_task_status``.' and advises setting timeout for large operations. It provides clear usage context but does not explicitly state when NOT to use it (e.g., if you want non-blocking behavior or to poll manually).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: pagination details (max_results, skip, next_link), total_count availability, return structure, and error slugs (not_found, auth_failed). This is comprehensive for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with Args and Returns sections, but it is slightly verbose for a simple tool. It could be trimmed while retaining all information, but it is not overly long and is front-loaded with purpose.
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 presence of an output schema, the description goes beyond expectations by detailing pagination, error handling, entry fields, and suggesting next steps (get_entry, get_field_values). It is fully complete for the tool's complexity.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value by providing practical usage context (e.g., 'root is typically ID 1', 'check next_link to know when to stop'), which enhances understanding beyond the schema descriptions alone.
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 'List the immediate children (documents and subfolders) of a folder by ID,' which is a specific verb and resource. It distinguishes itself from siblings like get_entry_by_path (path resolution) and search_natural/search_entries (full repository search) by explicitly mentioning alternatives.
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 clearly states when to use ('browse-style navigation when the user references a known folder') and when not to use ('To navigate from a path string, resolve it first with get_entry_by_path. To search across the whole repo, use search_natural or search_entries').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully compensates by detailing return structure (including failure modes with specific error slugs), case-sensitivity of template names, and optional parameter behavior. No contradictions with annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then follows a logical structure (workflow gap, args, returns). It is detailed yet not excessively long; every sentence adds value. Slight redundancy in return structure but overall well-organized.
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?
The description fully covers the tool's purpose, parameters, return values, error handling, and workflow context. Given the presence of an output schema (described), it leaves no gaps for an AI agent to function 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?
Schema coverage is 100% and both parameters are well-described. The description adds additional context like examples for template_name and practical use case for required_only, providing value beyond the schema alone.
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 clearly states 'Return the fields belonging to a single template, with full field metadata', using a specific verb and resource. It distinguishes itself from siblings like list_template_definitions and list_field_definitions by highlighting the workflow gap it fills.
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?
Provides explicit guidance: 'Use this BEFORE assign_template to construct the fields argument' and contrasts with alternatives 'instead of fetching list_template_definitions then list_field_definitions'. Clearly marks when and why to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: endpoint variability, fallback behavior on failure, non-raising nature, and output shape including 'mode' field to distinguish full vs fallback responses.
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 well-structured with sections for purpose, usage, endpoint variability, return shape, and failure behavior. Every sentence adds value, and it is appropriately 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 zero parameters, an output schema, and no annotations, the description fully covers the tool's behavior, return format, error handling, and edge cases, making it highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to add parameter information. It is sufficient and complete.
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 clearly states the tool lists repositories accessible by the account, with a specific verb ('List') and resource ('repositories'). It also distinguishes itself from sibling search tools by detailing its unique fallback behavior.
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 provides context for when to use the tool (confirming the current repository and discovering alternate ones), but does not explicitly exclude scenarios or contrast with sibling tools like 'laserfiche_repository_list'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It details return format (SearchResults with fields), error handling (returns error object with slugs), and mentions server fragility. Full disclosure of failure modes and their meanings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with usage guidelines first, then cheat sheet, then parameter details. Each sentence adds value, though slightly lengthy. Could be marginally shorter but efficient overall.
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?
Complete for a search tool: describes return format (even without output schema), error handling, and sibling relationships. No notable gaps given the complexity and existing schema coverage.
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?
Schema coverage is 100%, baseline 3. Description adds value by providing extra examples, clarifying maximum results cap, and explaining quoting rules in more plain language than schema. Not essential but beneficial.
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 clearly states it executes a raw Laserfiche query and returns entries, using specific verb 'run' and resource. It distinguishes from siblings by explicitly contrasting with search_natural and search_by_name.
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?
Explicit when-to-use (knowing query syntax), when-not (natural language or simple name), and provides alternatives with reasoning (search_natural for natural language, search_by_name for cheaper name lookup). Also includes a query syntax cheat sheet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it returns a dict grouped by operation type, details each item's fields, and describes failure responses including common error slugs like 'auth_failed'.
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 well-organized with distinct sections for purpose, usage, return value, and failure cases. Every sentence earns its place without redundancy.
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 zero parameters and the presence of an output schema, the description explains the return shape, error handling, and provides enough context for an agent to use 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?
No input parameters exist (empty schema), so baseline is 4. The description adds value by explaining the output structure and how to use the returned IDs, which is more than the schema provides.
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 clearly states 'Return the audit-reason codes the authenticated user is allowed to supply.' It specifies the exact verb and resource, and distinguishes from sibling tools by focusing on audit reasons.
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?
Explicitly instructs to use before 'delete_entry' or 'get_document_edoc' under specific conditions (LF_REQUIRE_AUDIT_REASON=true or audited delete). It tells the agent which IDs to pick from the response groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: v2-only, extraction pipeline (OCR for images, upstream for office), truncation with max_chars, detailed error slugs for various failure modes (not_found, method_not_allowed, server_error). Essentially all behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (Args, Returns, On failure) and bullet points. Some sentences are verbose but every sentence adds value. Could be slightly more compact without losing information.
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 has 2 parameters, an output schema, and complex behavior (version restriction, error handling), the description covers everything needed: input constraints, output format, error slugs, version fallback. The agent can fully understand how to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides good descriptions (100% coverage), but the description adds crucial context: entry_id must be an electronic document (not folder), max_chars defaults to 50000 and truncation is signaled by the 'truncated' field. This goes beyond what the schema defines.
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?
Description clearly states the tool downloads server-extracted text for electronic documents, with explicit use cases ('summarize this document', 'what does this say'). It distinguishes itself from get_document_edoc which provides raw binary, and from other siblings that retrieve different data types.
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?
Explicitly states when to use (tasks needing readable contents) and when not (v1 servers, raw binary needs). Provides fallback instruction to use get_document_edoc with mode='text'. No ambiguity about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: returns detailed payload (operationToken, operationType, percentComplete, status, redirectUri, entryId, errors, timestamps) and error responses with common slugs (not_found, auth_failed).
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?
Well-structured: brief summary, then context, alternative tool, detailed Args and Returns. Every sentence adds value; no redundancy. Front-loaded with purpose.
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 simplicity and presence of output schema, the description is comprehensive: covers purpose, usage, alternative, parameter semantics, and return values in detail, including errors.
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?
Input schema covers the only parameter (100% coverage). Description adds important context beyond schema: 'Server-scoped; tokens from a different server instance won't resolve,' which aids agent understanding.
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?
Clearly states the purpose: 'Look up the status of an async operation by its token.' Identifies the verb 'look up' and specific resource 'status of async operation,' and distinguishes from sibling tools like wait_for_task.
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?
Explicitly describes when to use: to check whether an async operation finished using an operation_token. Provides an alternative: 'For wait until done semantics, use wait_for_task instead so you don't have to write a polling loop.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully discloses behavior. It details the return format (grouped by operation type, each with id, name, description), failure modes (error slugs like auth_failed), and the fact that the entity is a query/list operation. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose and usage context. It is comprehensive but slightly verbose; minor trimming could improve conciseness without losing value.
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?
For a zero-parameter tool, the description is complete. It covers purpose, when to use, return format (including pseudo-schema), failure modes, and error handling. The output schema existence is noted, and the description provides a richer explanation than the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (schema is empty). Per calibration, baseline is 4. The description adds value by explaining the output structure and usage context, far exceeding the baseline. It fully compensates for the lack of parameters.
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 explicitly states 'Return the audit-reason codes the authenticated user is allowed to supply,' specifying a distinct verb and resource. It differentiates from sibling tools (e.g., get_entry, list_folder) which are general retrieval operations, whereas this tool returns codes for a specific use case.
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 provides explicit usage guidance: 'Use before delete_entry or get_document_edoc (with export auditing) when LF_REQUIRE_AUDIT_REASON=true or when the user is asking for an audited delete.' It also explains how to interpret the response and adapt behavior based on the operation type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: text source (OCR/extraction pipeline), truncation behavior, return format, and error slugs (not_found, method_not_allowed, server_error). It also explains the dependency on v2 and the fallback.
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?
Well-structured with clear sections (purpose, usage, args, returns). Front-loaded with the main action, then provides necessary details. Every sentence adds value; no redundancy.
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 complexity and presence of output schema, the description covers all aspects: input parameters, output structure, error handling, version dependency, and alternative tools. It is fully self-contained.
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?
Schema coverage is 100%, but the description adds value beyond schema: clarifies entry_id must be for an electronic document (not folder), specifies default max_chars (50,000), and explains the truncated response field.
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 clearly states the tool's action ('Download a document's server-extracted text'), specifies it's v2-only, and gives explicit use cases like 'summarize this document'. It distinguishes itself from siblings by mentioning the v1 limitation and fallback tool.
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?
Explicitly states when to use ('needs readable contents of a document') and when not to use ('v1 servers do not expose this endpoint'), including a direct alternative (use get_document_edoc with mode='text'). Also warns against using for folders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns a raw OData listing with specific fields, describes pagination (max_results, skip), the summary_only option, and failure mode ('On failure: returns error...'). No contradictions.
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?
Well-structured: opening sentence, usage context, parameter details with Args, return format, and failure mode. Each sentence is informative without redundancy. Front-loaded with the main purpose.
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 has 3 parameters and an output schema, the description covers purpose, usage context, all parameters, return format (including fields and error structure), and relationships with other tools. No gaps for an AI agent to invoke 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of summary_only (reduces payload for quick lookups) and noting that max_results is capped by LF_MAX_RESULTS_CEILING, which is not in the schema description.
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 clearly states it lists every field definition in the repository, specifies the types of information returned (field names, types, multi-value, required, list values), and distinguishes from siblings by mentioning 'Combine with list_template_definitions' to show template membership.
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?
Explicitly states when to use: 'before authoring a field-based search query or preparing a field update.' Also suggests combining with list_template_definitions for template-scoped fields, providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Details pagination behavior, max_results cap, return format including conditional total_count, and error slugs like not_found and auth_failed, with no annotations to contradict.
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?
Well-structured with purpose first, then usage, parameters, returns, and errors; all sentences are informative and focused.
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 moderate complexity, the description covers all aspects: purpose, usage, parameters, return format with fields, pagination, and error handling, making it self-contained.
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?
Input schema has 100% coverage, and description adds context like root folder default, page size default, and pagination usage, slightly exceeding baseline.
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 clearly states it lists immediate children of a folder by ID, using specific verbs and resources, and distinguishes it from siblings like search_natural and get_entry_by_path.
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?
Explicitly states when to use (browse-style navigation for known folders), provides default root ID, and names alternatives for path resolution and global search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses all behavioral traits: two-mode operation, automatic repair attempts (two specific strategies), pagination clamping and unknown pagination flag, error handling with structured error response, and reference to generic error contract for auth/rate limit/network failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings (Mode A, Mode B, Pagination, etc.), but it is somewhat verbose. It could be slightly more concise while retaining all necessary details, but the structure aids readability.
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?
Covers all aspects of the tool's behavior: modes, repairs, pagination, error handling, and limitations. The output schema likely details return structures, but the description already provides complete contextual guidance for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100%, the description adds significant value beyond field descriptions: e.g., lf_query's role in mode selection, folder_path's scoping difference between modes, fuzzy's repair condition, and max_results clamping rationale. This enriches the agent's understanding of parameter behavior.
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 clearly defines a two-mode search tool (guidance then execution), contrasting with sibling search tools by emphasizing natural language querying and automatic repair. It specifies the verb ('search') and resource ('Laserfiche entries') and distinguishes from alternatives like 'search_entries'.
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?
Explicitly explains when to use each mode (Mode A for guidance, Mode B for execution), what to expect, and what the tool does NOT do (no silent fallback). Provides guidance on embedding scope in lf_query and on setting fuzzy=False for exact matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return format, error slugs, and that the endpoint can be fragile on some builds.
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?
Front-loaded with purpose, then usage guidelines, cheat sheet, args, returns, and error handling. Every sentence adds value with no fluff.
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 existence of an output schema and 2 parameters, the description is complete, covering usage, errors, and providing a cheat sheet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining query structure, default max_results, capping, and error return format.
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 clearly states it runs a raw Laserfiche search query, and distinguishes from siblings like search_natural and search_by_name, providing specific verb+resource.
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?
Explicitly tells when to use this tool (already know query syntax) and when not (natural language → search_natural; simple name → search_by_name). Also provides a query syntax cheat sheet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral details: immediate return vs blocking, poll interval ignored when timeout=0, return value shape including timed_out field on wait variant, and failure shapes same as underlying tools. No annotations present, so description fully covers transparency.
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?
Well-structured: brief intro, bullet points for underlying tools, clear Args/Returns/On failure sections. Front-loaded with core behavior. Every sentence adds value without redundancy.
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 complexity of async polling/waiting, the description covers all aspects: mode selection, parameter behavior, return values (including timed_out), failure handling, and ties to underlying tools. Output schema exists but description still explains return shape. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant context beyond schema: operation_token examples (delete_entry, copy_entry, import_document), timeout_seconds bound by MCP client tolerance, poll_interval_seconds bounded below at 0.1s and ignored when timeout=0. Schema coverage is 100% but description enriches with practical details.
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 clearly states the tool checks or waits on async operations, differentiating two modes via timeout_seconds. It explicitly wraps get_task_status and wait_for_task, distinguishing from sibling tools like get_task_status and wait_for_task themselves.
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?
Provides explicit guidance: timeouts=0 for single-poll loops, timeout_seconds>0 for blocking wait. Mentions bounds on timeout and poll interval. Helps caller decide when to use this vs direct underlying tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![laserfiche-mcp MCP server](https://glama.ai/mcp/servers/SamuelSHernandez/laserfiche-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SamuelSHernandez/laserfiche-mcp)

Score Badge

Copy to your README.md:

[![laserfiche-mcp MCP server](https://glama.ai/mcp/servers/SamuelSHernandez/laserfiche-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SamuelSHernandez/laserfiche-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SamuelSHernandez/laserfiche-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server