fynk MCP

Create document from scratch

create-document-from-scratch

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.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	The name of the new document
`tag_uuids`	No	Optional UUIDs of the tags to apply to the document. UUIDs can be obtained from list-account-tags
`team_uuids`	No	UUIDs of the teams to assign the document to. May be required if the account enforces team assignment. UUIDs can be obtained from list-account-teams
`account_party_uuid`	No	Optional UUID of the account party to add to the document as the internal party. UUID can be obtained from list-account-parties

Output Schema

TableJSON Schema

Name	Required	Description
`url`	No	URL to open the document in fynk
`name`	No	Name of the document
`tags`	No	The tags on the document. 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.
`uuid`	No	Unique identifier for the document. Do not show to the user unless they ask for it
`stage`	No	What stage the document is in currently
`teams`	No	The teams the document is assigned to.
`locale`	No	Locale code, e.g. en-GB, de-AT. Absent when the document has none set. Prefer describing the locale in natural language (e.g. 'British English') rather than showing the raw code.
`origin`	No	How the document was created.
`parties`	No	The contracting entities on the document.
`conditions`	No	The document's conditions: rules over its dynamic fields deciding whether a passage of the document applies, and whether each currently holds. Use them to explain why a clause is or is not part of the document, and what would have to change to flip it.
`created_at`	No	When the document was created.
`updated_at`	No	When the document was last updated.
`archived_at`	No	When the document was archived. Absent when the document is not archived.
`signatories`	No	The individual people who sign the document. 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.
`_entity_type`	No	Only relevant for tooling. Do not show to the user
`summary_text`	No	A summary of the document content. Absent when the document has no summary.
`document_type`	No	If present, indicates what kind of document this is. Absent when the document has no type assigned
`dynamic_fields`	No	The document's dynamic fields and their values.
`signature_type`	No	eIDAS assurance level used when signing the document. Absent when none has been chosen.
`workflow_state`	No	Gives an indication of which stage transitions, etc are possible to perform on this document. This object is technical state, not display content: when relaying it to the user, always render it as natural-language prose and never echo raw field names or snake_case values (e.g. say 'signing cannot be started yet because not every signature block has been assigned to a signatory' instead of mentioning 'can_start_signing' or 'signature_block_signatory').
`metadata_values`	No	The document's metadata fields and their values.
`signature_blocks`	No	The places in the document 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. Every signatory needs a block covering them before signing can be started.
`sequential_signing`	No	When true, signatories sign one at a time, in ascending order of their signing_order.
`source_template_uuid`	No	UUID of the template the document was created from. Absent when it was not created from a template.
`external_signatory_invitation_message`	No	Text shown in the email inviting external signatories to sign. Absent when no message is set.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the document is created in the draft stage with no content, and the optional arguments expect UUIDs. It does not describe permissions or side effects of team assignment, but it exceeds the annotation baseline.

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 core action and well organized into condition, state, alternative, and parameter notes. Slightly verbose for a single-bullet 'Use this tool when' list, but every sentence carries information.

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

Completeness5/5

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

With an output schema present, return values need not be explained. The description covers the creation stage, the template alternative, and the discovery tools for the optional UUIDs, leaving nothing an agent needs to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters including their UUID sourcing. The description largely repeats the same discovery-tool mapping without adding format, constraint, or default details beyond the schema, so the baseline 3 is appropriate.

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 and resource (create a new empty document) and explicitly distinguishes itself from create-document-from-template by contrasting blank vs. template-based creation. An agent can route between the two siblings without opening either 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?

Contains an explicit 'Use this tool when' condition (user wants a blank document not based on a template) and names the alternative tool (create-document-from-template) with the condition that selects it. Nothing is left to inference.

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?