fynk MCP

Publish or unpublish template

set-template-published-state

Destructive

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`published`	Yes	true publishes the template, making it available to the whole account. false returns it to a draft, which only users who manage templates see and which replace-template-content can rewrite.
`template_uuid`	Yes	UUID of the template to publish or unpublish. Use list-templates to find it.

Output Schema

TableJSON 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
`uuid`	No	Unique identifier for the template. Do not show to the user unless they ask for it
`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.
`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
`_entity_type`	No	Only relevant for tooling. Do not show to the user
`document_type`	No	If present, indicates what kind of document this template creates. Absent when the template has no type assigned

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations flag destructiveHint=true and readOnlyHint=false, and the description goes well beyond that by disclosing the visibility model (drafts are visible only to template managers), the coupling with replace-template-content, and the important side-effect boundary that unpublishing leaves already-created documents untouched. It also sets an interaction expectation by instructing the agent to confirm before flipping state.

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?

The opening sentence is front-loaded and the bullet list is scannable and action-oriented. It runs long for a two-parameter boolean toggle, and a few sentences restate the same point ('publishing is what puts a template into service' echoes the opening), so it is efficient but not maximally tight.

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

Completeness5/5

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

For a low-complexity, two-parameter state toggle with an output schema (so return values need no explanation) and full annotation coverage, the description supplies everything an agent needs: direction semantics, prerequisites, visibility consequences, and the sibling it interacts with. Nothing material is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns extra credit by spelling out the practical consequences of each boolean value (account-wide availability vs. draft visibility and rewritability) and by noting that unpublishing has no retroactive effect on existing documents. It does not add UUID format or sourcing detail beyond what the schema already says.

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?

The description states a precise verb pair (publish/unpublish) plus the resource (template) and the resulting state change ('available to the whole account' vs 'back to a draft'). It is clearly distinguishable from siblings such as create-template-from-scratch and replace-template-content, which it explicitly contrasts.

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?

It enumerates concrete when-to-use triggers (template finished, documents needed from a draft, taking a template out of circulation, content rewrite blocked by replace-template-content) and names the sibling that fails without this call. It also gives the when-not/workflow rule: leave newly authored templates as drafts and confirm either direction with the user.

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?