Skip to main content
Glama
debitura

Debitura

Official

Create Collection Case

create_case
Destructive

Submit a debt collection case to initiate recovery against a debtor. Requires previewing pricing and obtaining explicit user confirmation before submission.

Instructions

Submit a debt collection case to Debitura. This is a LEGAL AND FINANCIAL ACTION: a collection partner starts recovery against the debtor, and contractual fees apply on success.

Required workflow — never skip it:

  1. Call preview_case first and show the user the pricing, assigned partner, and any contracts that need signing.

  2. Ask the user to explicitly confirm submission.

  3. Only then call this tool. NEVER call it without the user's explicit confirmation in this conversation.

Submission is idempotent: the server sends a unique Idempotency-Key and safely retries transient network failures without risk of duplicate cases. A 422 response is a business rejection — read its payload (it may contain signing URLs for required contracts, or duplicate-reference details).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoOptional tag for grouping test data
dateYesInvoice date (ISO 8601, e.g. 2026-03-01) — required by the API
debtorYesThe debtor the claim is against
isTestNoCreate as test data (persisted but excluded from production metrics)
dueDateYesInvoice due date (ISO 8601, e.g. 2026-04-30). Required — Debitura computes the age of the debt from it, which affects pricing.
commentsNoContext for the collection partner, e.g. payment history or prior communication
currencyCodeYesISO 4217 currency code, e.g. "EUR"
amountToRecoverYesTotal principal amount to recover
claimDescriptionNoDescription of the claim (what the debt is for)
assignedUserEmailNoEmail of the team member to own the case (use list_team_members to find valid team members)
creditorReferenceNoRECOMMENDED: your own reference (e.g. invoice number). Helps avoid business duplicates and lets you look the case up later.
allowPendingContractsNoAccept the case even if contracts (SDCA/POA) are unsigned — it waits in PendingContractSigning with signing URLs returned
Behavior5/5

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

Annotations indicate destructiveHint=true, but the description adds crucial context: it's a legal/financial action with contractual fees, idempotent behavior, and details on 422 responses (business rejection with signing URLs). No contradiction with annotations.

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

Conciseness5/5

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

Well-organized with clear sections: action description, required workflow (numbered steps), idempotency note, error handling. Every sentence adds meaningful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers behavior (idempotent, error details) and required context (preview_case, user confirmation). Could mention what a successful response contains (e.g., case ID), but overall sufficient for an agent to use 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; description adds value by referencing sibling tools for parameter population (list_team_members for assignedUserEmail, recommend creditorReference) and emphasizing the required preview_case workflow, though it doesn't detail each parameter beyond the schema.

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?

Description clearly states 'Submit a debt collection case to Debitura' with a specific verb and resource, and distinguishes from sibling tools like preview_case by outlining the required workflow.

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?

Explicitly provides a mandatory 3-step workflow (preview_case, user confirmation, then this tool) and warns never to call without explicit user confirmation, effectively guiding when to use this tool versus alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/debitura/Debitura.MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server