Skip to main content
Glama

Create account document type

create-account-document-type

Create a new custom document type for the account.

Use this tool when:

  • The user asks for a new kind of document to be distinguished, e.g. "add a Framework Agreement document type"

  • A document or template needs a document type that the account does not have yet

Call list-account-document-types first: fynk already provides system document types such as "Non-Disclosure Agreement", "Rental Agreement" or "Service Agreement" to every account, and a custom type that duplicates one of them splits the account's documents across two types. Create a new type only when none of the existing ones fits.

Write name in Title Case, the way fynk's own types are named ("Data Processing Agreement", "Letter of Intent"), rather than copying the user's phrasing verbatim - a request for "a type for supplier framework contracts" should produce "Supplier Framework Agreement".

description and prompt are how a new type is normally set up, so propose both from what the type is for rather than leaving them out:

  • description tells users what the type covers, in one sentence. fynk's "Rental Agreement" reads: "A contract between a landlord and tenant defining the terms under which property is rented, including duration, payment terms, and usage conditions."

  • prompt is what fynk's AI analyses read when deciding whether a document is of this type - without one, they rarely pick the type. Phrase it as a selection criterion, the way fynk's own types do. "Rental Agreement" reads: "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 decides which metadata fields fynk's AI analyses look for in documents of this type, besides the fields already relevant for every document type, which apply to the new type automatically. Call list-account-metadata to find the candidates, and propose the fields that type's documents would carry, e.g. a "Net Rent" field for a lease type. The fields chosen here are made relevant for the new type alongside the types they already have, and list-account-metadata reports the result: 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": {
      "name": "<name>"
    },
    "name": "create-account-document-type"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesName of the document type, unique among the account's custom document types, in Title Case (max 255 characters), e.g. "Supplier Framework Agreement"
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 ..."
descriptionNoOne sentence describing what the document type covers, shown to users (max 1024 characters)
relevant_metadata_uuidsNoUuids from list-account-metadata of the fields to make relevant for this document type, on top of the fields already relevant for every document type. Only the account's own fields and system_reference fields are accepted

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

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

Annotations only cover the safety profile (not read-only, not destructive, not idempotent, closed-world); the description goes well beyond them, explaining the consequence of creating a duplicate type, that a missing `prompt` makes AI analyses rarely select the type, and that `relevant_metadata_uuids` is additive and merges with the universal and existing type relevance. That is exactly the non-obvious behavioral context an agent needs before a mutation.

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 use-case bullets and well organized with headers and inline examples, but it runs long and the metadata relevance point is stated twice ('besides the fields already relevant for every document type, which apply automatically' and again 'made relevant alongside the types they already have'), which is redundant with the schema and with itself.

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?

Covers the full workflow for a mutation: when to create, prerequisite listing calls for both document types and metadata, content expectations for each optional field, and the naming convention. With an output schema present, no return-value explanation is needed, so nothing material is missing.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description still adds real meaning: Title Case normalization with a worked transformation ('a type for supplier framework contracts' → 'Supplier Framework Agreement'), the expected one-sentence shape of `description`, the 'Select this type if…' framing for `prompt`, and the discovery path (list-account-metadata) plus additive semantics for `relevant_metadata_uuids`.

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 custom document type for the account') and scopes it to the account, which cleanly separates it from the entity-level document/template creation siblings. The surrounding text makes clear it is the 'new type' operation, distinct from update- and delete-account-document-type.

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?

Has an explicit 'Use this tool when:' list with two concrete triggers, plus a hard precondition ('Call list-account-document-types first') and a negative rule ('Create a new type only when none of the existing ones fits'), with the reason given (duplicates split documents across two types). Alternative-first routing is spelled out rather than inferred.

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