Skip to main content
Glama

Update account document type

update-account-document-type
DestructiveIdempotent

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.

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": {
      "document_type_uuid": "<document_type_uuid>"
    },
    "name": "update-account-document-type"
  }
}

Input 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

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 declare destructiveHint=true and idempotentHint=true, but the description adds far more: the first change to a non-customised fynk type replaces it with a customised copy with a new uuid, moves documents and templates onto it, and requires `name`; resetting reverts the uuid; omitting a metadata uuid stops extraction while recorded values persist. These are non-obvious mutation consequences that the annotations alone cannot convey.

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 use cases, then parameter behaviour and edge cases in a logical order. It is on the long side and repeats a couple of points already in the schema (e.g. that null for description/prompt clears the value), costing a point on tightness, but no paragraph is irrelevant.

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 detailed, yet the description still notes that the tool returns the (possibly changed) uuid to use going forward. For a destructive, uuid-mutating tool with seven parameters, everything an agent needs to call it correctly is present.

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 real meaning beyond the schema: the `name` must be the name users know the type by (not a respelling) because the copy carries it in every language, and `prompt`/`relevant_metadata_uuids` are explained in terms of their downstream effect on AI analyses. It also clarifies the replace-not-append semantics of relevant_metadata_uuids and that universally relevant fields are unaffected.

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 and resource ('Change a document type the account can see') and immediately scopes it to both the account's own types and fynk's system types. This is clearly distinguishable from siblings like create-account-document-type, delete-account-document-type and list-account-document-types without opening any 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?

Provides an explicit 'Use this tool when' list covering rename, prompt sharpening, metadata relevance, reset and reactivate. It also states the alternatives/routing: get the uuid from list-account-document-types with include=["details"], and use reset_to_fynk_default or reactivate 'on its own' for those distinct cases rather than mixing them with a normal update.

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