fynk MCP

Publish or unpublish template

set-template-published-state

DestructiveIdempotent

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.

Tool call template

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

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

Input 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

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.5/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, and the description adds real context beyond them: unpublishing leaves already-created documents untouched, drafts are visible only to template managers, and publishing settles the body so replace-template-content can no longer write to it. It also tells the agent to confirm with the user before flipping state, which is meaningful for a destructive-hinted toggle.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the usage list are front-loaded well, but the piece is long for a two-parameter boolean toggle and repeats itself: the first sentence and 'Publishing is what puts a template into service' cover the same ground, as do the colleague-visibility remarks in the usage list and the confirm-with-them sentence. Trimming the redundancy would lose no 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, 100% parameter coverage, and annotations covering safety and idempotency, the description supplies everything else an agent needs: the draft/published lifecycle, the interaction with replace-template-content and list-templates, and the effect on existing documents. Nothing required to invoke it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and both parameter descriptions already spell out the true/false semantics of `published` and where to source `template_uuid`. The prose reinforces the consequences of each boolean value (visibility, rewriteability) but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 opening sentence gives a concrete verb pair and resource — publishes a template to the whole account or unpublishes it back to draft — and the scope (whole account vs. draft visibility) is stated explicitly. Siblings like replace-template-content and list-templates are named in their relationship to this state change, so an agent can place the tool precisely.

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?

A dedicated 'Use this tool when' list enumerates four concrete triggers, including the non-obvious case where a draft blocks replace-template-content. It also gives an explicit when-not workflow rule: a freshly authored template is left as a draft rather than published on the spot, and the user must confirm either direction.

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?