Skip to main content
Glama

List templates

list-templates
Read-onlyIdempotent

Get a paginated list of the templates available to the current user.

Use this tool when:

  • You need to know which templates are available for creating documents from

  • You need to know which templates the user may edit in fynk. These will have a "url" field pointing to the edit page. No "url" means no permission to edit

By default, returns all active (non-archived) templates that the user has access to, with the most recently updated templates first. sort_by and sort_direction arguments can be used to control the sorting.

To keep responses small, each template is returned as a compact summary by default. Use the include parameter to request additional sections (parties, teams, tags, details, signing_settings, timestamps) when the user's question needs them, and prefer get-template-info when you need full information about a single template.

The various 'filter_' arguments can be used to limit the list of returned templates.

Active vs. archived templates

Only active — i.e. not archived — templates are returned by default. Archiving is not deletion: an archived template still exists and its past documents still reference it. Set filter_archived_state=all when the answer is meant to cover every template the account has, and retry with it if a call returns no results, before concluding that no matching template exists. Set filter_archived_state=archived only when the user asks specifically about archived templates. When picking a template to create a new document from, keep the default: an archived template is one the account has retired from use. A response only reveals which templates are archived if you request include=["timestamps"], which carries archived_at.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list-templates"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoWhich page of results to fetch
includeNoOptional sections to include for each template, on top of the default compact summary. Allowed values: parties (the contracting entities the template defines, in compact form), teams (the teams the template is assigned to), tags (the account's own classification labels on the template), details (the template's description), signing_settings (signature type and sequential signing), timestamps (created_at, updated_at and archived_at — the last of these tells an archived template from an active one). Only request the sections you actually need; use get-template-info for full information about a single template.
sort_byNoSort results by this field. The default is: updated_at
per_pageNoHow many results to return on each page
filter_tagsNoA list of tag UUIDs. The default behavior is to match templates that have ANY of the given tags
filter_queryNoSearches against the template's name
filter_teamsNoA list of team UUIDs. Matches templates that belong to any of the given teams
filter_localeNoLocale code to filter by, e.g. "de" or "de-AT". Matches templates whose locale starts with the given value
filter_statusNoSet to "published" to return only published templates, or "draft" to return only drafts
filter_tag_andNoIf true, changes filter_tags behavior to only match templates that have ALL of the given tags. Sending false or omitting this filter has no effect
sort_directionNoThe default is: desc
filter_excluded_tagsNoA list of tag UUIDs. Templates with ANY of these tags will be excluded from the result
filter_archived_stateNoWhich templates to return, by archived state. "active" (the default) returns only active, non-archived templates; "archived" returns only archived templates; "all" returns both. Use "all" when the answer is meant to cover every template the account has; use "archived" only when the user asks specifically about archived templates. With "all" the response does not say which results are archived unless you also request include=["timestamps"]: archived_at is set on an archived template and null on an active one. Requires permission to manage templates — other users may only request "active"active
filter_team_unassignedNoIf true, finds templates that are not assigned to any team. May be combined with filter_teams to find templates that are in the given filter_teams OR are unassigned. Sending false or omitting this filter has no effect

Output Schema

NameRequiredDescriptionDefault
totalNoHow many templates are available across all pages
max_pageNoHow many pages of results are available
templatesNo
in_app_urlNoA URL that opens the fynk app's templates list with the same filters, sorting and pagination applied. Give this to the user when they may want to view or work with this filtered template list in the fynk app
current_pageNoWhich page of results this is

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world, so the bar is lower. The description nevertheless adds real behavior: default sorting (most recently updated first), the compact-summary default response shape, that a response only reveals archived status when include=["timestamps"] is requested, and that archived is not deletion. Missing detail on page size or how to iterate pagination, which keeps it at 4.

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?

Front-loaded purpose sentence, then a clear bulleted when-to-use list and a heading for the archived-vs-active distinction. Every section earns its place, though the archived-state explanation is repeated in the schema and again at length, making the description slightly longer than needed.

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 14-parameter list tool with output schema and rich annotations, the description covers what an agent needs: default scope, sorting, compact-vs-expanded responses, filtering, and the archived-state trap with its retry guidance. Return-value detail is handled by the output schema, so nothing critical is missing.

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, but the description adds cross-parameter context the schema doesn't tie together: which filter_ values limit the list, how sort_by/sort_direction interact with the default ordering, and the specific coupling of filter_archived_state with include=["timestamps"] to see archived_at. It stops short of explaining every one of the 14 parameters, so not a 5.

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?

States a specific verb (get a paginated list) and resource (templates available to the current user), and explicitly differentiates from the sibling get-template-info for full single-template info. An agent can tell exactly what this returns without opening the schema.

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?

Gives an explicit when-to-use list (finding which templates are available to create documents from, which the user may edit via presence of url), names the alternative (get-template-info for a single template), and specifies the retry rule with filter_archived_state=all before concluding no template exists. This is well beyond minimum viable.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources