fynk MCP ServerVerifiedFeatured

@fynk

Homepage Documentation

Basic information

Transport

Streamable HTTP

Authentication

OAuth

About fynk MCP Server

Draft, find, negotiate, analyze and sign contracts in fynk. Create documents via AI, from templates or PDFs, manage parties, signatories and fields, and send for e-signature, all with your own fynk permissions via OAuth.

#legal#contract management#CLM#digital signature#e-signature#document automation

Connection details

https://app.fynk.com/mcp

Setup

claude mcp add fynk --transport http https://app.fynk.com/mcp

fynk MCP Server tools

Archives a document, hiding it from the account's default document lists. Use this tool when: - A document is no longer actively worked with and should be moved out of the way - The user asks to archive, hide, or clean up a document Archiving does not delete anything: the document keeps all its data and can be restored later with the restore-document tool. The document must not already be archived.

Add one or more account users as members of a team. Use this tool when: - The user asks to add people to a team Existing members of the team are preserved. Use detach-account-users-from-team to remove members. Pass `account_user_uuids` from list-account-users, list-account-team-members (when copying members between teams), or the account-user uuids the user references.

Create a new custom document type for the account. Use this tool when: - The user asks for a new kind of document to be distinguished, e.g. "add a Framework Agreement document type" - A document or template needs a document type that the account does not have yet Call list-account-document-types first: fynk already provides system document types such as "Non-Disclosure Agreement", "Rental Agreement" or "Service Agreement" to every account, and a custom type that duplicates one of them splits the account's documents across two types. Create a new type only when none of the existing ones fits. Write `name` in Title Case, the way fynk's own types are named ("Data Processing Agreement", "Letter of Intent"), rather than copying the user's phrasing verbatim - a request for "a type for supplier framework contracts" should produce "Supplier Framework Agreement". `description` and `prompt` are how a new type is normally set up, so propose both from what the type is for rather than leaving them out: - `description` tells users what the type covers, in one sentence. fynk's "Rental Agreement" reads: "A contract between a landlord and tenant defining the terms under which property is rented, including duration, payment terms, and usage conditions." - `prompt` is what fynk's AI analyses read when deciding whether a document is of this type - without one, they rarely pick the type. Phrase it as a selection criterion, the way fynk's own types do. "Rental Agreement" reads: "Select this type if the document defines the terms under which a tenant rents property from a landlord, including rent amount, duration, deposit, and usage conditions." `relevant_metadata_uuids` decides which metadata fields fynk's AI analyses look for in documents of this type, besides the fields already relevant for every document type, which apply to the new type automatically. Call list-account-metadata to find the candidates, and propose the fields that type's documents would carry, e.g. a "Net Rent" field for a lease type. The fields chosen here are made relevant for the new type alongside the types they already have, and list-account-metadata reports the result: each field there names the document types it is relevant for.

Create a new account-level metadata field definition. Use this tool when: - The user asks for a new metadata field to track some piece of information on their documents - You need a metadata field to exist before writing values to it with update-document-metadata-values Call list-account-metadata first: the account may already have a field for what the user wants, and fynk provides a range of system metadata fields that cannot be re-created under the same name. `name` is the programmatic identifier (lowercase letters, digits and underscores only) and `display_name` is what the user sees. Write `display_name` in Title Case, the way fynk's own fields are named ("Signing Date", "Contract Value"), rather than copying the user's phrasing verbatim - a request for "a product colour metadata" should still produce `product_colour` / "Product Colour". `select` and `multi_select` fields require `select_values` (the allowed options); no other field type accepts them. These strings are literally what the user picks from in the UI, so write them as presentable labels, capitalised like `display_name`: "Red", "Green", "Blue", not the "red, green or blue" lifted out of the request. `name` and `value_type` are fixed at creation and cannot be changed afterwards, and it is worth getting the rest right first time rather than leaving a correction to make later. So confirm any detail the user has not spelled out instead of guessing at it - in particular the exact `select_values` strings, since a request like "a colour field with red, green or blue" names the options without settling how they should read. `prompt` and `keywords` decide whether fynk's AI analyses fill this field in - a `prompt` puts the field into them, `keywords` only assist it and do nothing on their own. This is how a new field is normally set up: fynk's own creation form turns AI analysis on by default and requires both. So propose a `prompt` and `keywords` drawn from what the field is for rather than silently leaving them out, and omit both only for a field the user wants to fill in by hand. Set a `description` as well - it is what tells a user configuring the field what it holds.

Create a new tag in the current account. Use this tool when: - The user asks to create a new tag - You need a new tag to be available before attaching it to documents or templates `name` (max 40 chars) and `color` (hex like "#FF0000") are required.

Create a new team in the current account. Use this tool when: - The user asks to create a new team - You need a new team to be available before attaching it to documents or templates The tool requires `name`. Do not ask the user about an icon — the team will use the default icon. Optionally pass `account_user_uuids` to add initial members. After creation, don't expose the UUID to the user.

Create a new document from a PDF previously uploaded via create-document-pdf-upload-url. Use this tool when: - The user wants to import an existing PDF into fynk as a draft document for further processing, OR - The user wants to record an already-signed PDF in fynk by setting initial_stage to "done" Call create-document-pdf-upload-url first to obtain `file_upload_uuid`, then upload the PDF to the URL it returns with a multipart/form-data POST, as that tool describes, before calling this tool. `initial_stage` is required and must be either "draft" or "done"; ask the user which they want if it isn't clear from context. Depending on the account's settings, `template_uuid` may be required (it copies checkpoints, document type, metadata, parties, etc. from a template). Only pass `auto_apply_ai_analysis` when the user has expressed whether AI analysis results should be applied to the document automatically; omit it to use the account's default setting. The `team_uuids`, `tag_uuids`, and `account_party_uuid` arguments expect UUIDs, which can be discovered via list-account-teams, list-account-tags, and list-account-parties respectively.

Create a new, empty document from scratch (not based on a template), optionally assigning teams, tags, and an account party. Use this tool when: - The user wants to start a new blank document that is not based on a template The document is created in the draft stage with no content. To create a document based on a template instead, use create-document-from-template. The `team_uuids`, `tag_uuids`, and `account_party_uuid` arguments expect UUIDs, which can be discovered via list-account-teams, list-account-tags, and list-account-parties respectively.

Create a new document from a template, optionally pre-filling parties, signatories, and dynamic fields, and optionally starting the signing process immediately. Use this tool when: - The user wants to generate a document based on an existing template It is usually helpful to call get-template-info with include=["parties", "signatories", "dynamic_fields"] first to discover the template's parties, signatories, and dynamic fields so that the `parties`, `signatories`, and `dynamic_field_values` arguments can be populated correctly. When completing dynamic fields, take note of the field's `type` when constructing the value. These are the rules to use when constructing the `value` string: - number: the numeric value in a string, using '.' as the decimal separator -> "1234.56" - currency: concatenate the ISO currency code and the numeric value with a ';' -> "EUR;1000.10" (for one thousand Euro and ten cents) - currency_duration: same as currency, but append another ';' followed by either `monthly` or `yearly` -> "EUR;1000.10;monthly" / "USD;1000.10;yearly" - select: one of the options from the field's `select_values` list -> "red" - multi_select: an array of the selected values in the `values` field -> ["red", "blue"] - bool: either of the strings "true" (displayed to the user as "Yes") or "false" (displayed to the user as "No") -> "true" / "false" - duration: a PHP-compatible duration specification -> "P6D" (6 days), "P2W" (2 weeks), "PT12H" (12 hours) - date: the date in the format "YYYY-MM-DD" -> "2026-12-31" - email, text, textarea, or any type not listed above: a string -> "test@example.com" Setting `start_signing=true` will move the new document straight into the signing stage and invite the signatories to sign it; this fails if any required information (party data, mandatory dynamic field values, signature blocks) is missing.

Adds a new party to a document. Use this tool when: - You need to add a new party to a document

Create a signed URL that a single PDF can be POST-uploaded to, for later use with create-document-from-pdf-upload. Use this tool when: - The user wants to create a document from an existing PDF file and you need somewhere to upload it to first Returns a `uuid` (pass it to create-document-from-pdf-upload after the upload completes), a `url` (target of the POST request), a `fields` map to send as form fields in the POST body before the file itself, and an `expires_at` timestamp after which the URL stops working.

Adds a signatory to a document. Use this tool when: - You have a document with one or more parties configured and want to add a signatory for one of the parties. When adding a signatory whose email corresponds to an existing user in the current fynk account, all of the optional arguments will be ignored and the signatory information will be populated from the existing user's profile.

Create a new dynamic field on a template. Use this tool when: - The user wants to add a variable / fill-in field (e.g. text, number, date, select) to a template - You are building up a template and need a placeholder whose value is filled in per document IMPORTANT: this is only the first of two steps. Creating the field does NOT place it in the template content, so on its own the fill-in placeholder will not appear in the document text. To make it show up, reference the returned `ref_uuid` in the template body (via replace-template-content) as: <span data-dynamic-field data-ref-uuid="<dynamic field ref_uuid>"></span> Until it is referenced in the content the field exists but is rendered nowhere. The same two-step pattern applies to signature blocks (create-template-signature-block, then `<div data-signatures><span data-signature-block data-ref-uuid="..."></span></div>`). Dynamic fields define the variable data filled in when a template is used to create a document. Each field has a `type` controlling what values it accepts, and a `scope` controlling who fills it in. A party's name or address is never a dynamic field. Both live on the party record: add the party with create-template-party and render its details in the content with <span data-party data-ref-uuid="..." data-format="name"></span>, taking data-format="address" for the address as a block and data-format="address:inline" for it on one line, as a preamble reads it. A document made from the template then follows its own parties. `select` and `multi_select` fields require `select_values` (the allowed options). The optional default value is set via `value` (for non-multi_select fields) or `values` (for multi_select fields). Construct the `value` string according to the field `type`: - number: the numeric value in a string, using '.' as the decimal separator -> "1234.56" - currency: concatenate the ISO currency code and the numeric value with a ';' -> "EUR;1000.10" - currency_duration: same as currency, but append another ';' followed by either `monthly` or `yearly` -> "EUR;1000.10;monthly" - select: one of the options from `select_values` -> "red" - multi_select: an array of the selected options in the `values` field -> ["red", "blue"] - bool: either of the strings "true" (shown as "Yes") or "false" (shown as "No") - duration: a PHP-compatible duration specification -> "P6D" (6 days) - date: the date in the format "YYYY-MM-DD" -> "2026-12-31" - email, text, textarea, or any type not listed above: a string -> "test@example.com"

Create a new empty template with editable ProseMirror content. Use this tool when: - The user wants to start building a new template from scratch (not from an existing PDF or template) The new template is created empty and its content is authored in a later step. The body references parties, dynamic fields and signature blocks by ref_uuid, so those have to exist before the content can point at them. Build the template in this order: 1. create-template-party for each contracting party. 2. create-template-signature-block for each party that signs. 3. create-template-dynamic-field for every value that varies per document - dates, amounts, notice periods, payment terms. A party's name or address is never one of them: both live on the party record and the content renders them from there. 4. replace-template-content once, with a body that references all of them by their ref_uuids and wraps each clause in an ordered list node so fynk numbers it. Authoring the content first and adding the parties, fields and signature blocks afterwards forces a second, destructive rewrite of the whole body to weave the references in, so plan them up front. This applies just as much when the content is derived from a source document such as a PDF: every filled-in blank in the source is a dynamic field unless it holds party identity, and its signature lines are signature blocks. The `locale` defines the template's content language and default number formats. Never ask the user for it - a BCP 47 tag is not something they can be expected to know. Infer it from the conversation, e.g. the language the content is to be written in or a country or jurisdiction the user names, and otherwise omit it, which falls back to the account's locale.

Add a party to a template. Use this tool when: - The user wants to add a party (e.g. a counterparty, customer, or employer) to a template - You are building up a template and need parties before adding signatories or signature blocks There are two ways to add a party: - Internal (saved) party: send `account_party_uuid` (from list-account-parties) together with `reference`. No other fields may be sent in this case. - External party: send `reference` and `scope`, and optionally `entity_name` and `address`. The two names on a party say different things: - `reference` is the generic label for the party's role on the template (e.g. "Employer", "Customer"), and stays the same for every document made from it. - `entity_name` is the name of the legal entity itself: a company's name ("Acme GmbH") or, when the party is an individual rather than an organisation, that person's name. On a template it is usually only known for the account's own side; a counterparty's is filled in per document, so leave it out rather than inventing one. To render the party's details inline in the template text, reference the returned `ref_uuid` in the body (via replace-template-content) as: <span data-party data-ref-uuid="<party ref_uuid>" data-format="name"></span> where `data-format` selects what is rendered: "name" (the party's entity/company name), "reference" (its reference label), "address", or "address:inline". A data-format is required. Note: adding a party does not, by itself, give that party anywhere to sign. If the party is meant to sign documents created from the template, follow up with create-template-signature-block for the party — and remember that the signature block must in turn be placed in the template content (via replace-template-content) inside a signature container, `<div data-signatures><span data-signature-block data-ref-uuid="..."></span></div>`, before it will appear on any document.

Add a signature block to a template, bound either to one of its parties or to a single signatory. Use this tool when: - The user wants a party to have a place to sign on documents created from the template - The user wants one specific signatory to have their own place to sign - You are building up a template and need to add signing slots Pass exactly one of `party_uuid` or `document_user_uuid`. A party-bound block is signed by every signatory of that party, whoever they turn out to be on a document created from the template; a user-bound block is signed only by the signatory it names. Use get-template-info with include=["parties", "signatories"] to discover the available parties and signatories and their UUIDs. A user-bound block requires a signatory that belongs to a party, because the block records that party alongside the signatory. IMPORTANT: this is only the first of two steps. Creating the signature block does NOT place it in the template content, so on its own it will not appear on any document. To make it show up, reference the returned `ref_uuid` in the template body (via replace-template-content) from a signature container, which houses one or more blocks: <div data-signatures data-align="left"><span data-signature-block data-ref-uuid="<signature block ref_uuid>"></span></div> A block is always placed inside such a container, even when it is the only one. Until it is referenced in the content the block exists but is rendered nowhere. The same two-step pattern applies to dynamic fields (create-template-dynamic-field, then `<span data-dynamic-field data-ref-uuid="...">`). `style` (regular or minimal) and `scale` (50–150, percent) are optional and default to "regular" and 100.

Remove a document type from the account, whether it is one of the account's own types or one of fynk's system document types. Use this tool when: - The user explicitly asks to delete or remove a document type `document_type_uuid` comes from list-account-document-types, and the user must have made clear which type they mean - either by naming it, or because it is the type this conversation has been about. Ask which one they mean when that is not clear, offering the candidates by name. What removing a type does depends on what list-account-document-types reports for it. A type the account created itself, without `provided_by_fynk`, is deleted for good. One of fynk's own types, with `provided_by_fynk`, is deactivated instead: it disappears from the account but can be brought back as fynk provides it with update-account-document-type and `reactivate: true`. A `customised` type loses its customisation either way, so tell the user so before going ahead with one. A type that documents or templates still use cannot be removed. The refusal says how many use it.

Delete one of the account's own metadata field definitions. Use this tool when: - The user explicitly asks to delete a metadata field `metadata_uuid` comes from list-account-metadata, and the user must have made clear which field they mean - either by naming it, or because it is the field this conversation has been about. Ask which one they mean when that is not clear, offering the candidates by their display name. Deleting a field also removes every value recorded for it, on every document and template in the account, and none of that can be brought back. So deleting a field the account has recorded values for is refused until the user has confirmed it: the refusal names the field and how many documents and templates hold a value for it - then repeat the call with `confirmed_deleting_values_in_use: true` once they have confirmed it. Send that only in answer to such a refusal, never as a matter of course. Put the effect to the user in their own terms and ask before going ahead - "deleting Discount Rate would also remove the value 12 documents hold for it, shall I go ahead?" - rather than quoting the refusal back at them. Name the field you are about to delete either way, and never delete more than the user asked for. Where the user wants a field to stop being filled in rather than to lose what it already holds, clear its `prompt` with update-account-metadata instead: that takes the field out of fynk's AI analyses and leaves the values on their documents alone. Only the account's own fields can be deleted. fynk's system fields are provided to every account and cannot be removed, `system_reference` fields included - use update-account-metadata to change how one of those is configured for this account. Deletion is refused while a bulk metadata operation is still running for the field.

Delete an existing tag. Use this tool when: - The user explicitly asks to delete a tag The specified tag is deleted and detached from documents and templates automatically.

Delete an existing team. Use this tool when: - The user explicitly asks to delete a team The specified team is deleted and detached from documents and templates automatically. Deletion will fail if the team is assigned as an approver on any template.

Remove a signatory from a document. Use this tool when: - A signatory was added in error or should no longer sign and the document has not yet been signed by them Identify the signatory to remove by `document_uuid` plus `signatory_email`. Removal may fail if the document's stage no longer permits signatory changes.

Delete a dynamic field from a template. Use this tool when: - The user explicitly asks to remove a dynamic field (a variable / fill-in field) from a template A dynamic field cannot be deleted while it is referenced by a condition or a metadata value on the template; remove those references first. Use get-template-info with include=["dynamic_fields"] to discover the dynamic fields on a template and their UUIDs.

Delete a party from a template. Use this tool when: - The user explicitly asks to remove a party from a template A party cannot be deleted while it still has signature blocks bound to it. Delete those signature blocks first with delete-template-signature-block. Use get-template-info to discover the parties on a template and their UUIDs.

Delete a signature block from a template. Use this tool when: - The user explicitly asks to remove a signature block (a party's signing slot) from a template The party the signature block belonged to remains on the template; only the signing slot is removed. Use get-template-info with include=["signature_blocks"] to discover the signature blocks on a template and their UUIDs.

Remove one or more account users from a team. Use this tool when: - The user asks to remove people from a team Only the account users listed in `account_user_uuids` are removed; other team members stay attached. Passing a user that is not on the team is a no-op.

Create a new draft document as a copy of an existing document. Use this tool when: - The user wants to duplicate or copy a document, e.g. to reuse a previous contract as the starting point for a new one with a different counterparty - A new agreement should start from an existing document rather than from a template The copy takes over the source document's content, parties, signatories, dynamic field values, metadata values, attachments, teams, tags, document type and template link. The new document always starts in the draft stage, whatever stage the source document is in, and a source document that is in signing or done is copied with its content as it was before signing started. Change what differs in the new document afterwards with the update-* tools, e.g. update-document-party for the counterparty or update-document-dynamic-fields for amounts and dates.

Create a new template as a copy of an existing template. Use this tool when: - The user wants to duplicate or copy a template, e.g. to build a variant of an existing contract for another jurisdiction or business line - A new template should start from an existing one rather than from scratch The copy takes over the source template's content, parties, signatories, signature blocks, dynamic fields, conditions, metadata values, attachments, teams, tags, document type, locale and published state. Documents already created from the source template stay linked to the source. Change what differs in the new template afterwards with the template tools, e.g. update-template-party, update-template-dynamic-field or replace-template-content. replace-template-content only writes a draft, so a copy of a published template has to be unpublished with set-template-published-state before its body can be rewritten.

Search the account's automations by name. Use this tool when: - You need an automation's UUID to filter list-documents by automation - You want to find automations matching a search term Returns automations whose name matches the query, most recently created first. Results are capped, so narrow the query if you don't find what you're looking for.

Search the account's document users (individual people who have access to documents) by name or email. Use this tool when: - You need a person's name to filter list-documents by document user - You want to find document users matching a search term Searches first name, last name and email. A two-word query is matched as firstname + lastname. Results are capped and de-duplicated by name, so narrow the query if you don't find who you're looking for.

Search the account's external parties (people and businesses that appear on documents) by name. External parties are the counterparties on documents — the entities on the OTHER side of an agreement, which do not belong to the account. They are distinct from account parties, which are the account's own entities (the company the user belongs to and its subsidiaries / group companies). Phrasing like "our", "we", "us", "my company" or "our subsidiary" refers to an account party, not an external party — in that case use list-account-parties instead. Use this tool when: - You need a party's name to filter list-documents by external party - You want to find parties matching a search term Matches the party's name (entity_name). Results are capped and de-duplicated by name, so narrow the query if you don't find who you're looking for. If you are looking for a named entity and it does not appear here, it may be an account party (the account's own side) instead — try list-account-parties before concluding it does not exist.

Search the account's imports by name. Use this tool when: - You need an import's UUID to filter list-documents by import - You want to find imports matching a search term Returns imports whose name matches the query, most recently created first. Results are capped, so narrow the query if you don't find what you're looking for.

Get information about the current fynk account. Use this tool when: - You need details about the active account (e.g. default document locale, signature settings) before tailoring a response - You are tailoring guidance to the account's business, and need what it reported about itself when signing up (industry, company size, the department the person who signed up works in) For information about the current user, use get-user-info

Gets information about a document. Use this tool when: - You have a document's UUID and want to know more details about it. e.g. who is signing it, what values its dynamic fields or metadata have, etc Called with no include parameter, returns the document's parties, teams, details, signatories, signing settings and workflow state. Use include to name the sections you want instead - among them dynamic_fields, conditions, metadata_values, signature_blocks, summary_text, tags and timestamps - and the response carries exactly those, so a question about one aspect of a document costs one section rather than the whole document. This tool covers a single document. Whenever possible avoid calling it once per document to gather the same information about several documents: list-documents returns parties, teams, tags and timestamps for a whole list via its include parameter, and specific metadata values for a whole list via its include_metadata parameter. Pass the UUIDs you already have to its filter_document_uuids parameter to get exactly the documents you are interested in. The default response lists both the document's parties (the contracting entities, frequently organizations) and its signatories (the individual people who sign). These are distinct: a person often signs on behalf of a party (e.g. a business) without appearing as a party, so consider the signatories — not just the parties — when answering whether a specific named person is involved in or signs a document. The dynamic_field_visibility argument narrows the dynamic_fields section to the fields that appear in the document itself, or to the ones that do not. A field belonging to a document is not necessarily written into it: fields get added and then never placed in the text, or the passage that referred to one gets rewritten, leaving a value no reader ever sees. Not every not_visible field is idle, though. Some exist only to drive a condition deciding which clauses the document shows, so they shape the contract without appearing in it (you can use the "conditions" include option to see which fields drive which conditions). Others sit inside a passage that a currently inactive condition removes, so they would appear if that condition flipped. Use "visible" when the question is about what the contract currently says. dynamic_field_visibility has no effect unless dynamic_fields is among the returned sections. The workflow_state object - in the response by default, and requestable via include alongside other sections - describes what can currently be done with the document: whether the signing process can be started at all, which stages the document can be moved on to and everything standing in the way of each of them (stage_transitions, whose blockers say why), whether the requesting user can start signing, and — when a checkpoint blocks progress — who still needs to approve. Use it to answer questions like "why can't I sign this yet?", "what is blocking this document?" or "who still has to sign?", answering with the full list rather than one problem at a time. It is technical state, not display content: relay it to the user as natural-language prose and never echo raw field names or snake_case values.

Get a download URL for the latest revision of a document as a PDF. Use this tool when: - The user wants to download the current state of a document as a PDF - You need a PDF link to share with the user for review Returns the URL as plain text. The URL is short-lived; fetch a new one if it expires before download.

Returns the content of a template serialised as HTML. Use this tool when: - You want to read or navigate the content of a template - You want to understand the structure of a template before editing it The HTML uses semantic data-* attributes to represent fynk-specific nodes such as dynamic fields, party references, and signature blocks. Addressable nodes (paragraphs, headings, etc.) carry a data-uuid attribute that can be used to target individual nodes in subsequent operations. Clause numbering is dynamic. Numbered clauses are ordered list nodes — `<div data-list data-kind="ordered">` — that contain the clause text and, when nested, sub-clauses. Their computed number is shown read-only via a `data-number` attribute (e.g. `data-number="1.1."`). Numbers are never part of the text; do not treat them as editable content. A cross-reference to a clause appears as `<span data-section-ref data-uuid="...">`, where data-uuid is the data-uuid of the list node it points at. It is empty: what it renders is that clause's computed number, so it follows the clause rather than stating a number of its own. Dynamic fields (fill-in placeholders) appear inline as `<span data-dynamic-field data-ref-uuid="...">`, where data-ref-uuid is the field's ref_uuid (see get-template-info include=["dynamic_fields"]). Signature blocks are grouped in a signature container — `<div data-signatures data-align="..."><span data-signature-block data-ref-uuid="..."></span></div>` — where each `<span data-signature-block>` points at one block by its ref_uuid (see get-template-info include=["signature_blocks"]). Legacy content may still show a block outside any container, as `<div data-signature-block data-ref-uuid="...">`; writing it back turns it into a container holding that one block. Party references appear as `<span data-party data-ref-uuid="..." data-format="name|reference|address|address:inline">`, where data-format selects what is rendered (name = the party's entity_name, reference = its reference name). Images (`<img data-image>`), dynamic tables (`<div data-dynamic-table>`) and signing vote blocks (`<span data-signing-vote-block>`) appear as empty reference tags. Their contents are held outside the HTML and cannot be created or edited through it, so copy these tags over unchanged when rewriting the template; dropping one removes the image or table from the template. Text formatting - bold, colour, font, size, highlight - is stated inline, as the style of the tag carrying it. A block's layout is not: the margins, indent and line height a paragraph or heading is laid out with stay on the block itself, so the HTML says nothing about them. A block's alignment is stated, as `data-text-align` on the paragraph, heading or list node carrying it - left, center, right or justify - with a matching `text-align` style alongside it. A block carrying neither is aligned left. Only available for templates with a prosemirror_data content type. Returns an error for PDF templates.

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 and timestamps - and the response carries exactly those, so a question about one aspect of a template costs one section rather than the whole template.

Get information about the current user. Use this tool when: - You need to know who the current user is (email, locale, roles) before tailoring a response For information about the current fynk account, use get-account-info

Joins a document as a collaborator. Use this tool when: - You need to make changes to a document, but do not have a 'document user' in the document yet. - You need to make changes to a document, but your existing 'document user' does not yet have permission to change it.

Get a list of the document types available in the account (fynk's system-provided types plus any custom types defined for the account). Use this tool when: - You need a document type's UUID to filter list-documents by document type - You want to know which document types exist before referring to them by name in a response - You need to know what a document type covers, or how fynk's AI analyses recognise it (include=["details"]) Each document type is returned as its uuid and name by default. Request include=["details"] for its description and the prompt the AI analyses use to recognise it. Which metadata fields a document type has is reported from the other side, by list-account-metadata: each field there names the document types it is relevant for. By default, only the types the account currently offers are returned. Removing one of fynk's system types deactivates it rather than deleting it: set filter_state to "deactivated" to list those types (e.g. when the user wants to reactivate one) or to "all" to list them alongside the rest.

Get a list of the metadata fields available in the account to be associated with documents & templates. Use this tool when: - You need to know which metadata names exist before referencing them in get-document-info / list-documents - You want to know the type, allowed values, or other configuration of an account's metadata fields

Get a list of the account parties saved on your account. Account parties are the account's OWN entities — the company the user belongs to and its subsidiaries, group or parent companies. Phrasing like "our", "we", "us", "my company" or "our subsidiary" refers to an account party. These are the internal side of an agreement, as opposed to external parties (the counterparties on the other side), which you find with find-external-parties. Use this tool when: - You need to know which pre-defined parties are available for use in documents or templates - You need to provide an account_party_uuid (use a uuid from this tool's response) - You need an account party's UUID to filter list-documents by account party (filter_account_parties) — e.g. to find documents involving "our" company or one of its subsidiaries If you are looking for a named entity and it does not appear here, it may be an external party (counterparty) instead — try find-external-parties before concluding it does not exist.

Get a list of the playbooks defined in the account. Use this tool when: - You need a playbook's UUID to refer to it - You want to know which playbooks exist before referring to them by name in a response Playbooks allow automating the review of documents based on predefined criteria.

Get a list of the tags available in the account to be associated with documents & templates. Use this tool when: - You need a tag's UUID to filter list-documents / list-templates by tag - You want to know which tags exist before referring to them by name in a response

List the members (account users) of a given team. Use this tool when: - You need the account-user uuids of a team's members in order to add them to another team - The user asks who is in a team - You are merging or restructuring teams and need to know the current membership Returns each member's uuid, first_name, last_name, and email. Pass the uuids to attach-account-users-to-team to add the same people to another team. Suspended users are not included.

Get a list of the teams available in the account. Use this tool when: - You need a team's UUID to filter list-documents by team - You want to know which teams exist before referring to them by name in a response

Get a list of the account users (the people who can log in to this fynk account). Use this tool when: - You need an account user's uuid, e.g. to add them to a team via attach-account-users-to-team - The user refers to a colleague by name and you need to match them to an account user - The user asks who is part of the account Returns each account user's uuid, first_name, last_name, and email. Only the account users the current user is allowed to see are returned: most users see everyone in the account, but 'limited manager's only see themselves and the members of their own teams. So this list is not necessarily the full set of people in the account - avoid presenting it as complete.

Get a paginated list of the documents available to the current user. Use this tool when: - You need to find a document_uuid to use as input for another tool - You need to know which documents the current user has access to - You want to search for a specific document By default, returns all active (non-archived) documents that the user has access to, with the most recently updated documents first. sort_by and sort_direction arguments can be used to control the sorting. Archived documents are included or targeted using the filter_archived_state parameter. To keep responses small, each document 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-document-info when you need full information about a single document. When you need particular metadata values for several documents, name those fields in include_metadata and they are returned for every document in the response. Do not call get-document-info once per document to collect the same fields — one list-documents call with include_metadata answers the whole question. When you already have the UUIDs of the documents you care about, pass them as filter_document_uuids and combine that with include or include_metadata to gather information about exactly those documents in a single call. # Each account has its own vocabulary — discover it before filtering Accounts classify their documents using structures they define themselves: tags, document types, metadata fields (and their select options), teams and parties. The words a user puts in a question are usually the words their own account already uses as labels. "our customers", "suppliers", "key accounts", "renewals", "EMEA" and "high value" all sound like descriptions of content, but each is far more likely to be a tag, a document type, or a metadata field or option in this account. Tags in particular are the account's own free-form classification labels, commonly covering relationship type (customer, supplier, partner, reseller), commercial significance (key account, strategic), lifecycle or region. A plain category noun in a question very often corresponds to a tag rather than to anything in the document text — so check list-account-tags whenever a question groups documents into a category that isn't available as a document type. These lookups are cheap and return small, complete lists, so look rather than guess: - list-account-tags: the account's classification labels - list-account-document-types: e.g. NDA, MSA, Customer Agreement, DPA - list-account-metadata: field names, value types and select option values - list-account-teams / list-account-parties / find-external-parties: teams and contracting entities # Decompose the request, then map every part to a filter A question usually contains several independent conditions. Handle each one separately: 1. Split the request into its conditions. "what logo usage rights do we have for our largest customers?" is three: "logo usage rights", "largest", "customers". 2. For each condition, ask what kind of structured thing it could be: a tag, a document type, a metadata field or option, a party (account or external), a document user, a team, a template, an automation, an import, a stage, or an origin. 3. Look up the candidates with the companion tools above, then filter with the matching filter_ parameter. 4. Only leave a condition to filter_query once you have confirmed that no structured filter covers it. Finding a structured filter for one condition does NOT mean you are done — work through every condition before answering. In the example above, "largest" is a currency metadata field such as contract value (filter_metadata range, or sort_by that field), "customers" is very likely a tag or a document type, and "logo usage rights" may also be available from a metadata. Answering with just one of the three silentl…

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.

Moves a document to the done stage. Use this tool when: - The document's current stage is one of: draft, approved_draft, review, approved_review - The document will NOT be signed through fynk (documents signed through fynk automatically move to done when fully signed) This stage transition may be blocked by checkpoints on the document, or by unresolved preconditions (unresolved proposals, mandatory dynamic fields without values, active editor sessions or working copies, active signing phases, etc.). A refusal here reports just the first problem it runs into; call get-document-info first and read workflow_state.stage_transitions.done.blockers to see everything that is in the way at once.

Moves a document to the review stage. Use this tool when: - The document's current stage is one of: draft, approved_draft, approved_review, signing or done - You want to share the document for review before moving to a later stage This stage transition may be blocked by checkpoints on the document, or - when reverting a document that was not created from a template - by an account that only allows signing to start from a template. A refusal here reports just the first problem it runs into; call get-document-info first and read workflow_state.stage_transitions.review.blockers to see everything that is in the way at once. If the document is in the process of being signed, or has been signed already, moving back to review will cancel the current signing process and invalidate any existing signatures.

Moves a document to the signing stage and invites signatories to sign. Use this tool when: - The document's current stage is one of: draft, approved_draft, review, approved_review - You want to start the signing process This stage transition may be blocked by checkpoints on the document, or by unresolved preconditions (missing signature blocks, unresolved proposals, mandatory dynamic fields without values, active editor sessions or working copies, etc.). A refusal here reports just the first problem it runs into; call get-document-info first and read workflow_state.stage_transitions.signing.blockers to see everything that is in the way at once. If the document has a signature_type set, the signature_type argument - if provided - must match it; otherwise the document's signature_type will be used. If the document has no signature_type, the one provided here (or the account default) will be used. A qes or aes_eid signature_type requires sequential_signing=true. aes_eid is only available when the account has enabled AES (eID) in its settings.

Replaces the ENTIRE content of a draft template from an HTML string in a single destructive write. Use this tool ONLY when: - You are authoring the initial content of an empty, freshly created template (e.g. after create-template-from-scratch), or - The user has explicitly asked to discard the current content and rewrite the whole template. This is the right tool for laying down a large body of content at once (e.g. a whole NDA). It writes the whole template body in one go; there is no way to edit an individual node. Do NOT use this tool to edit a template that already has content. Overwriting throws the existing content away. If the template already has content, this tool refuses to run unless you pass replace_existing_content=true to confirm the destructive overwrite. Read the current content with get-template-html first, so anything worth keeping can be carried over into the new HTML. Overwriting an existing body cannot be undone, so ask the user to confirm it before passing replace_existing_content=true. Only allowed on unpublished (draft) templates. Once a template is published its content can no longer be changed with this tool. Use the same data-* attribute conventions as get-template-html. UUIDs present on nodes (e.g. data-uuid on a paragraph or heading) are preserved; nodes without a UUID are assigned one automatically. The returned HTML reflects the stored result, with every addressable node carrying a data-uuid you can use in subsequent operations. Each data-uuid identifies exactly one node, so no two nodes may carry the same one. When you copy an existing node to build a similar one, drop its data-uuid (a fresh one is assigned on write) - reusing it is rejected and nothing is written at all. A cross-reference is the one exception: it carries the uuid of the clause it points at rather than one of its own, so that uuid appears twice by design. Numbering follows the source. A block the source numbers becomes an ordered list node; a block it does not keeps the tag it had - an <h2> stays an <h2>, prose stays a <p>. A source that numbers nothing gets no list node at all: a contract written entirely as headings and paragraphs is a correct result. Headings go three levels deep, <h1> to <h3>. An <h4> or deeper is rejected and nothing is written, so carry a hierarchy past three levels with nested list nodes rather than with a deeper heading. The numbers themselves are ALWAYS computed by fynk, never typed into the text. HTML whose text starts with a clause marker ("1. Confidentiality", "2)", "(a)", "iv.", "§ 5") is rejected and nothing is written. Where the source numbers a clause, wrap it in an ordered list node instead: <div data-list data-kind="ordered" data-numbering-type="continue"><p>Confidentiality.</p></div> <div data-list data-kind="ordered" data-numbering-type="continue"><p>Term.</p></div> Nest another such `<div data-list>` inside a clause to create sub-clauses (1.1, 1.2). fynk computes the numbers (1., 2., 1.1., …) automatically and returns them as read-only `data-number` attributes, which are ignored on input. To cross-reference a clause, give that clause a data-uuid of your own - any uuid you generate, as long as it appears on exactly one node - and point the reference at it: <div data-list data-kind="ordered" data-uuid="11111111-1111-4111-8111-111111111111"> <p>Confidentiality.</p></div> … <p>As set out in <span data-section-ref data-uuid="11111111-1111-4111-8111-111111111111"></span>, notices are written.</p> which renders the clause's computed number ("1.") in place of the reference, following it wherever the clause moves rather than hardcoding it. Both go in the same call: there is no need to write the body first and read the uuids back. A cross-reference carrying no data-uuid points at nothing and is rejected, so drop the reference where you have no clause to name. A list node decides how its own number is rendered, so any scheme a source document uses is c…

Restores an archived document, making it show up in the account's default document lists again. Use this tool when: - An archived document should become actively used again - The user asks to restore or unarchive a document The document must currently be archived. Archived documents do not appear in list-documents results by default: pass `filter_archived_state: "archived"` to the list-documents tool to find them.

Publishes a template, making it available to the whole account, or unpublishes it back to a draft. Use this tool when: - A template is finished, the user has read it over and asks to publish it, release it or hand it to their colleagues - Documents are to be created from a template that is still a draft - The user asks to take a published template out of circulation - A published template's content has to be rewritten, which replace-template-content refuses until the template is a draft again Publishing is what puts a template into service. list-templates shows a draft only to the users who manage templates, so until it is published nobody else can find it to create a document from. It also settles the body, which replace-template-content only writes while the template is a draft. A template that was just authored is therefore left as a draft rather than published on the spot. Tell the user what was written, let them read it over, and publish once they say it is right. Confirm either direction with them: publishing offers the template to their colleagues, unpublishing takes it away from them. Unpublishing changes nothing about the documents already created from the template. They keep the content they were created with; the template is simply no longer offered for new ones.

Change a document type the account can see, whether it is one of the account's own types or one of fynk's system document types. Use this tool when: - The user asks to rename a document type, or to change what it covers - AI analyses keep picking the wrong document type, or miss one, and its `prompt` needs sharpening - The user asks to change which metadata fields are relevant for documents of a type - The user asks to put one of fynk's document types back to how fynk provides it - The user asks to bring back one of fynk's document types that was removed from the account `document_type_uuid` comes from list-account-document-types; request include=["details"] there to see a type's current description and prompt. Send only the arguments that should change; everything left out keeps its current value. Sending `null` for `description` or `prompt` clears it. list-account-document-types marks fynk's own document types with `provided_by_fynk`, and those this account has customised with `customised` as well. A change to one of fynk's types applies to this account alone. The first change to one that is not `customised` yet replaces it, for this account, with a customised copy that has a uuid of its own, and moves the account's documents and templates onto it; use the uuid this tool returns from then on. That first change must include `name`, because the copy carries its name as written here in every language the account's users read fynk in, instead of fynk's translations. So send the name the user knows the type by, e.g. "Non-Disclosure Agreement", rather than a respelling of the listed name. Send `reset_to_fynk_default: true` on its own for a `customised` type to drop the customisation, putting fynk's own name, description and prompt back and moving the documents and templates back onto it. The type's uuid changes back to fynk's, which this tool returns. A type that list-account-document-types reports as `deactivated` (with filter_state "deactivated" or "all") is one of fynk's that was removed from the account. Send `reactivate: true` on its own to bring it back as fynk provides it; customise it afterwards with a further call. `prompt` is what fynk's AI analyses read when deciding whether a document is of this type. Phrase it as a selection criterion, the way fynk's own types do: "Select this type if the document defines the terms under which a tenant rents property from a landlord, including rent amount, duration, deposit, and usage conditions." `relevant_metadata_uuids` replaces the metadata fields specifically relevant for the type, which decides the fields fynk's AI analyses look for in documents of this type. Send every field that should remain: one left out is no longer extracted from the type's documents, though values already recorded stay. Fields relevant for every document type apply regardless and are unaffected. list-account-metadata reports the current state: each field there names the document types it is relevant for.

Change the definition of a metadata field the account can see, whether it is one of the account's own fields or a `system_reference` field provided by fynk. Use this tool when: - The user asks to rename a metadata field, or to change what it holds - The user asks to start or stop having fynk's AI analyses fill a field in - The user asks to change which document types a field applies to - The user asks to put one of fynk's fields back to how fynk provides it `metadata_uuid` comes from list-account-metadata. Send only the arguments that should change; everything left out keeps its current value. Sending `null` for `description`, `prompt` or `keywords` clears it. A field's `name` and `value_type` are fixed at creation and this tool cannot change either. To rename a field for the people using it, change `display_name` - in Title Case, the way fynk's own fields are named ("Signing Date", "Contract Value"). fynk's own `system_reference` fields can be reconfigured per account: the change applies to this account alone and leaves the field as fynk defines it everywhere else, and putting an argument back to fynk's own value stops overriding it. fynk's other system field types (`system`, `system_autofilled`, `system_computed`) are maintained entirely by fynk and cannot be changed at all. One of fynk's fields that an account has reconfigured reports the arguments it overrides as `overridden_fields`, from this tool and from list-account-metadata alike. Send `reset_to_fynk_default: true` on its own to drop all of them at once, leaving the account reading the field exactly as fynk provides it; there is no per-argument reset, so re-send whichever of them are still wanted afterwards. `select_values` replaces the whole list of options, which are literally what a user picks from, so write them as presentable labels: "Net 30", not "net 30". They govern what can be chosen from now on and leave values already recorded on documents as they are, so prefer adding an option to renaming or removing one. Since the list is replaced wholesale, send every option that should remain: one left out is one taken away. Taking away an option that documents already hold is refused until the user has confirmed it. Such a value stays on its document but can no longer be filtered for. The refusal names the options and how many documents and templates still use each - then repeat the call with `confirmed_removing_options_in_use: true`. Send that only in answer to such a refusal, never as a matter of course. `reset_to_fynk_default` is covered the same way, since putting fynk's own options back takes away any the account added to them. Put the effect to the user in their own terms and ask before going ahead - "removing Net 90 would affect 3 documents that still use it, shall I go ahead?" - rather than quoting the refusal back at them. `prompt` and `keywords` decide whether fynk's AI analyses fill this field in - a `prompt` puts the field into them, `keywords` only assist it and do nothing on their own. So set both together to have a field extracted, and clear `prompt` to take a field back out of the analyses and leave it to only be filled in by hand.

Update an existing tag's name and/or color. Use this tool when: - The user asks to rename a tag - The user asks to change a tag's color `tag_uuid` is required. Send only the fields that should change.

Update an existing team's name and/or icon. Use this tool when: - The user asks to rename a team - The user asks to change a team's icon `team_uuid` is required. Send only the fields that should change.

Update the value of one or more of a document's dynamic fields. Use this tool when: - You want to fill in (or change) values for fields like text inputs, dates, numbers, or selects on a document - A user asks to set values that signing requires before it can begin (mandatory dynamic fields) Each entry in `dynamic_field_values` identifies the field by its `ref_uuid` or `name` (use get-document-info with include=["dynamic_fields"] to discover them) — sending the wrong key will fail validation. Take note of the field's `type` when constructing the value. These are the rules to use when constructing the `value` string: - number: the numeric value in a string, using '.' as the decimal separator -> "1234.56" - currency: concatenate the ISO currency code and the numeric value with a ';' -> "EUR;1000.10" (for one thousand Euro and ten cents) - currency_duration: same as currency, but append another ';' followed by either `monthly` or `yearly` -> "EUR;1000.10;monthly" / "USD;1000.10;yearly" - select: one of the options from the field's `select_values` list -> "red" - multi_select: an array of the selected values in the `values` field -> ["red", "blue"] - bool: either of the strings "true" (displayed to the user as "Yes") or "false" (displayed to the user as "No") -> "true" / "false" - duration: a PHP-compatible duration specification -> "P6D" (6 days), "P2W" (2 weeks), "PT12H" (12 hours) - date: the date in the format "YYYY-MM-DD" -> "2026-12-31" - email, text, textarea, or any type not listed above: a string -> "test@example.com" To unset a dynamic field, send a null value.

Set or unset the value of one or more of a document's metadata. Use this tool when: - You want to fill in (or change) a document's metadata values - You want to remove a value the document currently has for a metadata Each entry in `metadata_value_changes` identifies the metadata by its `metadata_uuid` or `name` (use list-account-metadata, or get-document-info with include=["metadata_values"], to discover them) — sending an identifier that does not match any of the account's metadata will fail validation. Each entry also has an `operation`: - `set`: create the metadata value (if the document does not have one yet) or update the existing value - `unset`: remove the document's value for the metadata (no value is required) For a `set`, take note of the metadata's `value_type` when constructing the value. These are the rules to use when constructing the `value` string: - number: the numeric value in a string, using '.' as the decimal separator -> "1234.56" - currency: concatenate the ISO currency code and the numeric value with a ';' -> "EUR;1000.10" (for one thousand Euro and ten cents) - currency_duration: same as currency, but append another ';' followed by either `monthly` or `yearly` -> "EUR;1000.10;monthly" / "USD;1000.10;yearly" - select: one of the options from the metadata's `select_values` list -> "red" - multi_select: an array of the selected values in the `values` field -> ["red", "blue"] - bool: either of the strings "true" (displayed to the user as "Yes") or "false" (displayed to the user as "No") -> "true" / "false" - duration: a PHP-compatible duration specification -> "P6D" (6 days), "P2W" (2 weeks), "PT12H" (12 hours) - date: the date in the format "YYYY-MM-DD" -> "2026-12-31" - email, text, textarea, or any type not listed above: a string -> "test@example.com" Some metadata cannot be changed this way (e.g. computed metadata, or metadata whose value is driven by a dynamic field) — attempting to do so will fail validation.

Edit the details of a party on a document. Use this tool when: - A party's reference, entity type, entity name, address, or scope needs to change on an existing document `document_uuid` and `party_identifier` (a `ref_uuid`, `reference`, or `entity_name` of a party on the document) are required to identify the party. All other arguments are optional and only need to be sent if their value should change. For parties linked to an account party, only `party_reference` can be changed — attempting to update other fields will fail.

Edit the details of a document signatory. Use this tool when: - A signatory's name, title, mobile phone, or party assignment needs to change before signing starts - You need to move an existing signatory to a different party on the document `document_uuid` and `signatory_email` are required to identify the signatory. All other arguments are optional and only need to be sent if their value should change. For internal signatories (linked to an account user), `signatory_first_name`, `signatory_last_name`, and `signatory_title` cannot be changed — they come from the user's profile.

Adds tags to and/or removes tags from a document. Use this tool when: - One or more tags should be added to a document - A tag should be removed from a document - A document's tag should be replaced with another (one `remove` and one `add` action) Actions are applied on top of the document's current tags: tags not mentioned in `tag_actions` stay attached. Each tag may appear in at most one action per call. Adding an already-attached tag or removing a tag that is not attached has no effect. Use the `list-account-tags` tool to discover valid tag UUIDs, and the `create-account-tag` tool to create a new tag first if no suitable one exists.

Adds teams to and/or removes teams from a document. Use this tool when: - A document should be assigned to one or more teams - A team assignment should be removed from a document - A document should be moved from one team to another (one `remove` and one `add` action) Actions are applied on top of the document's current team assignments: teams not mentioned in `team_actions` keep their assignment. Each team may appear in at most one action per call. Adding an already-assigned team or removing a team that is not assigned has no effect. Use the `list-account-teams` tool to discover valid team UUIDs. Some accounts enforce team assignment, in which case the last remaining team cannot be removed.

Updates a document's name, locale, document type, signing settings and/or external signatory invitation message. Use this tool when: - A document should be renamed - The document's content language (locale) or document type should change - The signature type or sequential signing setting should change before signing starts - The message included in the email inviting external signatories should be set or changed All arguments except `document_uuid` are optional and only need to be sent if their value should change. `signature_type` and `sequential_signing` cannot be changed once signing has started, and `signature_type` cannot be changed if it was specified by the document's template. Use the `list-account-document-types` tool to discover valid document type UUIDs. This tool cannot change the document's stage (use the `move-document-to-*-stage` tools for that).

Update an existing dynamic field on a template. Use this tool when: - The user wants to change a dynamic field's name, scope, options, default value, or other properties Only send the fields you want to change. A field's `type` cannot be changed after creation; to change the type, delete the field and create a new one. `select` and `multi_select` fields still require non-empty `select_values`. The default value is set via `value` (for non-multi_select fields) or `values` (for multi_select fields), formatted according to the field's type (see create-template-dynamic-field for the per-type format). Setting a default value clears any autofill configured on the field. Use get-template-info with include=["dynamic_fields"] to discover the dynamic fields on a template and their UUIDs and types.

Update an existing party on a template. Use this tool when: - The user wants to change a party's role label, entity details, or scope - The user wants to link an existing external party to a saved account party, or unlink it again Only send the fields you want to change. `reference` is the party's role label on the template (e.g. "Employer"). Account party linkage: - Send `account_party_uuid` (from list-account-parties) to link the party to a saved account party. While linked, only `reference` may be changed; `entity_name`, `address`, and `scope` cannot be sent. - Send `account_party_uuid` as null to unlink the party, turning it back into an external party whose entity details and scope you can then set. Use get-template-info to discover the parties on a template and their UUIDs.

Update the presentation of a signature block on a template. Use this tool when: - The user wants to change how an existing signature block looks (its style or scale) Only `style` (regular or minimal) and `scale` (50–150, percent) can be changed. The party a signature block belongs to cannot be reassigned; to move a signature block to a different party, delete it and create a new one. Use get-template-info with include=["signature_blocks"] to discover the signature blocks on a template and their UUIDs.

Overview

What is fynk MCP?

fynk is a European contract management platform for drafting, negotiating, signing and managing contracts. The fynk MCP server connects your AI assistant (Claude, ChatGPT, Cursor or any MCP client) to your fynk workspace, so you can manage contracts in plain language without opening the app.

What you can do

Find and understand contracts: search documents, check stages, dates, parties, signatories and metadata, and download PDFs
Create documents: from a template (with parties, signatories and fields pre-filled), from scratch, or from an uploaded PDF
Edit documents: update dynamic fields, metadata, parties, signatories, tags and teams
Run the workflow: move documents to review, signing or done, start e-signatures (SES, AES, QES), archive and restore
Build templates: create parties, signature blocks, dynamic fields and content, then publish
Manage your account setup: tags, teams, document types and metadata fields

Example prompts

"Which contracts with Acme are still in signing, and who hasn't signed yet?"
"Create an NDA from our Mutual NDA template for Globex, effective 1 November, and add Jane Doe as signatory."
"What's blocking the Globex Services Agreement from going to signature?"

Setup

An account owner or admin enables MCP under Account Settings → MCP in fynk.
Add https://app.fynk.com/mcp as a custom connector in your AI client.
Sign in with fynk and approve the connection.

Requirements

fynk Essential, Business or Pro plan (or 14-day free trial). No API keys or custom OAuth app needed: clients register automatically via OAuth.

Security and privacy

The assistant acts with your own fynk role and permissions and can't see or do anything you couldn't.
Admins can see every connection and disconnect it at any time.
fynk data is hosted in the EU and fynk is ISO 27001 certified. Data returned to your AI client is handled under that provider's terms.

Frequently asked questions

What is the fynk remote MCP server?

The fynk remote MCP server is a hosted Model Context Protocol endpoint at https://app.fynk.com/mcp, so AI assistants can connect to it without installing or running anything locally.

How do I connect to the fynk MCP server?

Add the endpoint https://app.fynk.com/mcp to any MCP-compatible client such as Claude Code, Cursor, or VS Code. The setup snippets on this page configure each client in one step.

Does the fynk MCP server require authentication?

Yes. fynk uses OAuth: the first time you connect, your MCP client opens a browser window to sign in and authorize access, then reuses the credentials for future sessions.

Which transport does the fynk MCP server use?

fynk exposes a Streamable HTTP endpoint, the transport used by remote MCP servers and supported by all major MCP clients.

Comments

More remote MCP servers

AIsa

AIsa is one key for 950+ data APIs across SEO and AI visibility, finance, social, web search, sales and agent mail — the go-to-market data stack behind prospecting, competitor research and brand monitoring. Five tools ra

3GPP Scout

Hosted 3GPP MCP server: cited search across Rel-15 through Rel-20 TS/TR specs, recent TDocs, company proposals and meeting decisions. OAuth 2.1; no local index required.

AWS Marketplace

Discover, evaluate, and buy solutions for the cloud

API Direct

Search and read public data from X/Twitter, Reddit, YouTube, Instagram, TikTok, Facebook, Threads, Bluesky, Trustpilot, Amazon, Google Maps, news, forums and the web. 90+ read-only tools plus ready-made research playbook

AWS Knowledge MCP Server

Search and read current AWS documentation, check regional availability and load AWS agent skills, with no AWS account needed.

About fynk MCP Server

Connection details

Setup

fynk MCP Server tools

archive-document

attach-account-users-to-team

create-account-document-type

create-account-metadata

create-account-tag

create-account-team

create-document-from-pdf-upload

create-document-from-scratch

create-document-from-template

create-document-party

create-document-pdf-upload-url

create-document-signatory

create-template-dynamic-field

create-template-from-scratch

create-template-party

create-template-signature-block

delete-account-document-type

delete-account-metadata

delete-account-tag

delete-account-team

delete-document-signatory

delete-template-dynamic-field

delete-template-party

delete-template-signature-block

detach-account-users-from-team

duplicate-document

duplicate-template

find-automations

find-document-users

find-external-parties

find-imports

get-account-info

get-document-info

get-latest-document-pdf

get-template-html

get-template-info

get-user-info

join-document

list-account-document-types

list-account-metadata

list-account-parties

list-account-playbooks

list-account-tags

list-account-team-members

list-account-teams

list-account-users

list-documents

list-templates

move-document-to-done-stage

move-document-to-review-stage

move-document-to-signing-stage

replace-template-content

restore-document

set-template-published-state

update-account-document-type

update-account-metadata

update-account-tag

update-account-team

update-document-dynamic-fields

update-document-metadata-values

update-document-party

update-document-signatory

update-document-tags

update-document-teams

update-document

update-template-dynamic-field

update-template-party

update-template-signature-block

Overview

What is fynk MCP?

What you can do

Example prompts

Setup

Requirements

Security and privacy

Links