fynk MCP

Delete account document type

delete-account-document-type

DestructiveIdempotent

Remove a document type from the account, whether it is one of the account's own types or one of fynk's system document types.

Use this tool when:

The user explicitly asks to delete or remove a document type

document_type_uuid comes from list-account-document-types, and the user must have made clear which type they mean - either by naming it, or because it is the type this conversation has been about. Ask which one they mean when that is not clear, offering the candidates by name.

What removing a type does depends on what list-account-document-types reports for it. A type the account created itself, without provided_by_fynk, is deleted for good. One of fynk's own types, with provided_by_fynk, is deactivated instead: it disappears from the account but can be brought back as fynk provides it with update-account-document-type and reactivate: true. A customised type loses its customisation either way, so tell the user so before going ahead with one.

A type that documents or templates still use cannot be removed. The refusal says how many use it.

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": "delete-account-document-type"
  }
}

Input Schema

Name	Required	Description	Default
`document_type_uuid`	Yes	Uuid of the document type to remove, from list-account-document-types

Output Schema

Name	Required	Description	Default
`deleted_document_type`	No	The account's own document type, as it was before it was deleted for good. Present only when one of the account's own types was removed
`deactivated_document_type`	No	One of fynk's document types, now deactivated for this account. Present only when one of fynk's types was removed

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?

Despite annotations already declaring destructiveHint=true and idempotentHint=true, the description adds substantive behavior: account-owned types are deleted permanently, fynk-provided types are only deactivated and recoverable, and customised types lose their customisation. It also discloses the failure mode (a type in use cannot be removed, and the refusal reports usage count), which annotations cannot express.

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 core action, then organized into a bulleted trigger and two paragraphs of consequences. Slightly long, but every sentence carries operational information (disambiguation, soft vs hard delete, dependency refusal) rather than filler.

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 destructive single-parameter mutation with an output schema available, the description covers the prerequisites, the two distinct deletion semantics, the irreversible customisation loss, and the blocked case. Nothing an agent needs to warn the user about before calling 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 parameter is already documented, but the description adds real value by stating provenance (from list-account-document-types) and the requirement that the user has unambiguously identified the type. It stops short of format details, so it is a modest step above the baseline 3.

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 first sentence names a specific verb (Remove) and resource (a document type from the account) and even scopes the target set to both account-owned and fynk system types. An agent can distinguish it immediately from create-account-document-type and update-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?

It gives an explicit trigger ('The user explicitly asks to delete or remove a document type'), explains how to source the uuid from list-account-document-types, and instructs the agent to disambiguate by offering candidates by name. It also names the reactivation path via update-account-document-type as the inverse operation.

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?