fynk MCP

by com.fynk.app

Overview Discussions Admin

Create template party

create-template-party

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.

Input Schema

TableJSON Schema

Name	Required	Description
`scope`	No	When internal_and_external, collaborators from this party may change the party's information. Required when account_party_uuid is not sent.
`address`	No	Party's address. Cannot be sent alongside account_party_uuid
`reference`	Yes	Generic reference for the party's role on the template. e.g. "Counterparty", "Customer", "Employer"
`entity_name`	No	Name of the legal entity that is party to the contract - a company's name, or a person's name when the party is an individual. Cannot be sent alongside account_party_uuid
`template_uuid`	Yes	UUID of the template to add the party to
`account_party_uuid`	No	To add a saved account party, the uuid of a party from the list-account-parties tool. When provided, only reference may accompany it.

Output Schema

TableJSON Schema

Name	Required	Description
`uuid`	No	Identifier for the party - unique to the specific instance of the party. Do not show to the user unless they ask for it
`address`	No	The party's address. Absent when not yet known
`ref_uuid`	No	A static reference identifier, allowing parties in documents to be matched their corresponding party in the document's source template. Do not show to the user unless they ask for it
`reference`	No	A generic reference for the party. e.g. "Customer", "Employee", etc
`entity_name`	No	The actual name of the party. Absent when not yet known
`is_internal`	No	True if the party belongs to this account
`_entity_type`	No	Only relevant for tooling. Do not show to the user

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only declare the safety profile (not read-only, not destructive, closed-world); the description adds materially more: the internal-vs-external field exclusivity rules, that adding a party grants no signing ability, and the downstream steps required before a document is affected. It does not cover permissions/auth requirements or what happens on duplicate references, so it falls short of a 5.

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 with the action and the when-to-use list, then organized into clearly labeled subsections (two ways to add, the two names, rendering, follow-up note). It is long for a create tool and repeats some schema-level constraints, keeping it just short of a 5, but every section carries operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the description still supplies the missing workflow context: how to render the party inline via ref_uuid in replace-template-content, the valid data-format values, and the signature-block follow-up. For a 6-parameter, 2-mode mutation tool this is complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics the schema does not: the conceptual difference between reference (role label, stable across documents) and entity_name (legal entity, usually omitted for counterparties), plus the rule that entity_name/address 'cannot be sent' with account_party_uuid. That goes beyond a restatement of field docs.

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+resource ('Add a party to a template') and immediately disambiguates from siblings like update-template-party, create-document-party and delete-template-party by scoping the operation to templates and to creation. An agent can identify what this does 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?

Explicit 'Use this tool when' bullets name the triggering user intent and the workflow position (parties must exist before signatories/signature blocks). It names list-account-parties as the source of account_party_uuid and create-template-signature-block as the required follow-up, so alternatives and sequencing are spelled out rather than implied.

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?