Skip to main content
Glama

Update account document type

update-account-document-type
Destructive

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew name of the document type, unique among the account's document types, in Title Case (max 255 characters), e.g. "Supplier Framework Agreement". Required on the first change to one of fynk's document types
promptNoSelection criterion the AI analyses use to decide whether a document is of this type (max 1024 characters), phrased like "Select this type if the document ...". null clears it, after which the analyses rarely pick the type
reactivateNoOnly true, sent on its own: brings back one of fynk's document types that is deactivated for this account, with its default settings
descriptionNoOne sentence describing what the document type covers, shown to users (max 1024 characters). null clears it
document_type_uuidYesUuid of the document type to change, from list-account-document-types
reset_to_fynk_defaultNoOnly true, sent on its own: drops the account's customisation of one of fynk's document types, returning it to fynk's own configuration and uuid
relevant_metadata_uuidsNoReplaces the fields specifically relevant for this document type: uuids from list-account-metadata, of the account's own fields and system_reference fields. Send every field that should remain; an empty list or null leaves only the fields relevant for every document type

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName of the document type
uuidNoIdentifier for the document type. Do not show to the user unless they ask for it
promptNoThe selection criterion fynk's AI analyses use to decide whether a document is of this type. Absent when it has none, in which case the analyses rarely pick the type.
customisedNoPresent, and true, only for a system document type that this account has customised. The customisation can be dropped again with update-account-document-type and `reset_to_fynk_default`
descriptionNoWhat the document type covers, as shown to users configuring it. Absent when it has none.
_entity_typeNoOnly relevant for tooling. Do not show to the user
provided_by_fynkNoPresent, and true, only for one of fynk's built-in system document types. The account can customise or deactivate such a type but never delete it. Absent for a type the account created itself

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag destructiveHint=true; the description goes far beyond that, disclosing that the first change to a non-customised fynk type replaces it with a customised copy with a new uuid, moves documents/templates onto it, and changes uuid again on reset. It also warns that omitting relevant_metadata_uuids stops future extraction (existing values persist) and that nulling prompt makes analyses rarely pick the type.

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 purpose and a scannable 'Use this tool when' list, then dense but necessary paragraphs on the customisation/uuid lifecycle. It is long and occasionally repetitive (the naming instruction is restated), but for a seven-parameter mutation tool with this many edge cases nearly every sentence carries required 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, and the description still covers the uuid-changes-on-return behavior. Given the complexity of customisation, reactivation, and metadata replacement, the coverage is complete enough for an agent to invoke it 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 baseline is 3, but the description adds real cross-parameter semantics: 'Send only the arguments that should change', null clears description/prompt, reset_to_fynk_default and reactivate must be sent on their own, and name is mandatory on the first change to a fynk type. It also gives phrasing guidance for prompt.

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?

Opens with a specific verb+resource+scope: '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.' This distinguishes it cleanly from create-account-document-type, delete-account-document-type, and list-account-document-types, which are all named siblings.

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?

An explicit 'Use this tool when:' bullet list enumerates five concrete triggers (rename, sharpening a prompt, changing metadata relevance, resetting to fynk default, reactivating a removed type). It also routes the agent to list-account-document-types as the source of document_type_uuid and names the special single-argument cases, leaving little to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources