fynk MCP

Get template info

get-template-info

Read-onlyIdempotent

Gets information about a template.

Use this tool when:

You have a template's UUID and want to know more details about it.
e.g. when you want to create a document from the template and need to know which parties, dynamic fields, etc are available in the template.

Called with no include parameter, returns the template's identity, its parties, its teams, its description and its signing settings. Use include to name the sections you want instead - among them signatories, signature_blocks, dynamic_fields, conditions, metadata_values, tags, timestamps, attachments and stored_files - and the response carries exactly those, so a question about one aspect of a template costs one section rather than the whole template.

The stored_files section holds what the app shows as "Internal file storage", separate from attachments: call them that when talking to the user, never "stored files".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "template_uuid": "<template_uuid>"
    },
    "name": "get-template-info"
  }
}

Input Schema

Name	Required	Description	Default
`include`	No	The sections the response carries, on top of the template's identity (uuid, name, locale, document type, published, url), which it always carries. Naming sections means exactly those: ask for one section and you pay for one, rather than for the whole template. If omitted, these are returned: parties, teams, details, signing_settings.
`template_uuid`	Yes	UUID of the template to get information about

Output Schema

Name	Required	Description
`url`	No	URL to open the template in fynk. Only present when your user has template editing permission
`name`	No	Name of the template
`tags`	No	The tags on the template. Tags are the account's own classification labels (e.g. relationship type, commercial significance, region), so they show which categories this account uses and can be filtered on with filter_tags. Only present when the 'tags' section is requested via the include parameter.
`uuid`	No	Unique identifier for the template. Do not show to the user unless they ask for it
`teams`	No	The teams the template is assigned to. Only present when the 'teams' section is requested via the include parameter.
`locale`	No	Locale code, e.g. en-GB, de-AT. Prefer describing the locale in natural language (e.g. 'British English') rather than showing the raw code.
`parties`	No	The contracting entities the template defines. Only present when the 'parties' section is requested via the include parameter.
`published`	No	Indicates if the template is published (true) or a draft (false). Only published templates can be used by users without template management permission
`conditions`	No	The template's conditions: rules over its dynamic fields deciding whether a passage of the template applies, and whether each currently holds. Use them to explain why a clause is or is not part of the template, and what would have to change to flip it. Only present when the 'conditions' section is requested via the include parameter.
`created_at`	No	When the template was created. Only present when the 'timestamps' section is requested via the include parameter.
`updated_at`	No	When the template was last updated. Only present when the 'timestamps' section is requested via the include parameter.
`archived_at`	No	When the template was archived. Absent when the template is not archived. Only present when the 'timestamps' section is requested via the include parameter.
`attachments`	No	The files attached to the template. Attachments are part of the template itself and visible to external parties. Absent when the requesting user may not view the template's files. Only present when the 'attachments' section is requested via the include parameter.
`description`	No	Description of the template. Absent when the template has none. Only present when the 'details' section is requested via the include parameter.
`signatories`	No	The individual people who sign documents created from this template. Distinct from parties: a signatory often signs on behalf of a party (e.g. a business), so a person may be a signatory without appearing as a party. Only present when the 'signatories' section is requested via the include parameter.
`_entity_type`	No	Only relevant for tooling. Do not show to the user
`stored_files`	No	The files in the template's internal file storage, as opposed to its attachments. The app shows these files as "Internal file storage": call them that when talking to the user, never "stored files". Absent when the requesting user may not view the template's files. Only present when the 'stored_files' section is requested via the include parameter.
`document_type`	No	If present, indicates what kind of document this template creates. Absent when the template has no type assigned
`dynamic_fields`	No	The template's dynamic fields and their values. Only present when the 'dynamic_fields' section is requested via the include parameter.
`signature_type`	No	The eIDAS assurance level that will be used when signing documents created from this template. Absent when none has been chosen. Only present when the 'signing_settings' section is requested via the include parameter.
`metadata_values`	No	The template's metadata fields and their values. Only present when the 'metadata_values' section is requested via the include parameter.
`signature_blocks`	No	The places in the template that are signed. A block is bound either to a single signatory or to a party, in which case every signatory of that party signs it. Only present when the 'signature_blocks' section is requested via the include parameter.
`sequential_signing`	No	Whether signatories must sign in a specific order. Only present when the 'signing_settings' section is requested via the include parameter.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 6, 2026

changedInput schema / properties / include / items / enum

Previous value: -[
-  "parties",
-  "teams",
-  "tags",
-  "details",
-  "signing_settings",
-  "timestamps",
-  "conditions",
-  "dynamic_fields",
-  "metadata_values",
-  "signatories",
-  "signature_blocks"
-]New value: +[
+  "parties",
+  "teams",
+  "tags",
+  "details",
+  "signing_settings",
+  "timestamps",
+  "attachments",
+  "conditions",
+  "dynamic_fields",
+  "metadata_values",
+  "signatories",
+  "signature_blocks",
+  "stored_files"
+]

addedOutput schema / properties / attachments

Added value: +{
+  "description": "The files attached to the template. Attachments are part of the template itself and visible to external parties. Absent when the requesting user may not view the template's files. Only present when the 'attachments' section is requested via the include parameter.",
+  "items": {
+    "properties": {
+      "_entity_type": {
+        "description": "Only relevant for tooling. Do not show to the user",
+        "enum": [
+          "attachment"
+        ],
+        "type": "string"
+      },
+      "file_size": {
+        "description": "Size of the file in bytes. Use file_size_display when telling the user the size",
+        "type": "integer"
+      },
+      "file_size_display": {
+        "description": "Size of the file formatted for display, e.g. \"2.4 MB\"",
+        "type": "string"
+      },
+      "filename": {
+        "description": "Name of the file",
+        "type": "string"
+      },
+      "sha256": {
+        "description": "SHA-256 digest of the file's bytes, as lowercase hex. Equal digests mean byte-identical files. Do not show to the user unless they ask for it",
+        "type": "string"
+      },
+      "uuid": {
+        "description": "Identifier for the attachment. Do not show to the user unless they ask for it",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / stored_files

Added value: +{
+  "description": "The files in the template's internal file storage, as opposed to its attachments. The app shows these files as \"Internal file storage\": call them that when talking to the user, never \"stored files\". Absent when the requesting user may not view the template's files. Only present when the 'stored_files' section is requested via the include parameter.",
+  "items": {
+    "properties": {
+      "_entity_type": {
+        "description": "Only relevant for tooling. Do not show to the user",
+        "enum": [
+          "stored_file"
+        ],
+        "type": "string"
+      },
+      "file_size": {
+        "description": "Size of the file in bytes. Use file_size_display when telling the user the size",
+        "type": "integer"
+      },
+      "file_size_display": {
+        "description": "Size of the file formatted for display, e.g. \"2.4 MB\"",
+        "type": "string"
+      },
+      "filename": {
+        "description": "Name of the file",
+        "type": "string"
+      },
+      "sha256": {
+        "description": "SHA-256 digest of the file's bytes, as lowercase hex. Equal digests mean byte-identical files. Do not show to the user unless they ask for it",
+        "type": "string"
+      },
+      "uuid": {
+        "description": "Identifier for the stored file. Do not show to the user unless they ask for it",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

First observedOct 20, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false and openWorldHint false, so safety is covered; the description goes further by disclosing the default section set (identity, parties, teams, description, signing settings) and the payload-cost model of include. It also flags a user-facing terminology rule for stored_files vs attachments, which is genuine behavioral context not present in structured fields. It stays silent on permissions/auth requirements and error behavior for an unknown UUID.

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-loads the purpose, then uses a bulleted when-to-use block and a paragraph on include semantics, so structure is easy to scan. It loses a little to duplication with the include schema description and to a parenthetical section list that repeats the enum.

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?

Covers what the tool does, when to use it, what each include selection yields, and the terminology to use with the user; an output schema exists so return shapes need not be explained. Remaining gaps are minor: no sibling comparison for the read-only template tools and no mention of failure modes for a bad UUID.

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% and the include property's schema text already enumerates the thirteen sections, the always-returned identity fields, and the defaults when omitted. The description mostly restates that in prose, adding only the cost framing ("one section rather than the whole template"); template_uuid gets no added meaning beyond the schema.

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?

States a specific verb and resource ("Gets information about a template") and scopes it to a UUID-addressed single template, which separates it from list-templates and create-document-from-template. It never names a sibling tool explicitly, so an agent must still infer the boundary versus get-template-html, duplicate-template, or get-document-info.

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 an explicit "Use this tool when" block with a concrete scenario: you have a template UUID and need to know which parties, dynamic fields, etc. are available before creating a document. It gives no negative guidance, so nothing tells the agent when to reach for get-template-html or list-templates instead.

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

All fynk MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?