Cross-border debt collection: submit and track cases handled by local partners in 183 countries.
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:
Call preview_case first and show the user the pricing, assigned partner, and any contracts that need signing.
Ask the user to explicitly confirm submission.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional tag for grouping test data | |
| date | Yes | Invoice date (ISO 8601, e.g. 2026-03-01) — required by the API | |
| debtor | Yes | The debtor the claim is against | |
| isTest | No | Create as test data (persisted but excluded from production metrics) | |
| dueDate | No | Case due date (ISO 8601). When omitted with claimLines, Debitura uses the oldest line due date. | |
| comments | No | Context for the collection partner, e.g. payment history or prior communication | |
| claimLines | No | Unpaid invoices making up the claim. Use instead of amountToRecover and age buckets; Debitura derives the total and aging. | |
| currencyCode | Yes | ISO 4217 currency code, e.g. "EUR" | |
| amountToRecover | No | Total principal amount. Omit when sending claimLines | |
| claimDescription | No | Description of the claim (what the debt is for) | |
| assignedUserEmail | No | Email of the team member to own the case (use list_team_members to find valid team members) | |
| creditorReference | No | RECOMMENDED: your own reference (e.g. invoice number). Helps avoid business duplicates and lets you look the case up later. | |
| allowPendingContracts | No | Accept the case even if contracts (SDCA/POA) are unsigned — it waits in PendingContractSigning with signing URLs returned | |
| amountToRecoverOver6Months | No | Cumulative principal more than 180 days overdue | |
| amountToRecoverOver12Months | No | Cumulative principal more than 365 days overdue | |
| amountToRecoverOver24Months | No | Cumulative principal more than 730 days overdue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses major behavioral traits (legal/financial action, contractual fees, 422 error handling, idempotency), but it directly contradicts the annotations: the description states 'Submission is idempotent' while the idempotentHint annotation is false. Per the rubric, any contradiction yields a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and a numbered workflow. It is thorough and each sentence earns its place, though it could be slightly compressed without losing value. The front-loading of the purpose and the explicit 'NEVER' warning make it effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 16-parameter tool with nested objects and no output schema, the description covers the critical workflow, safety warnings, error handling, and idempotency semantics. It lacks return value details, but that is not required without an output schema. The idempotency contradiction slightly undermines completeness, but overall it is quite thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 16 parameters with descriptions (100% coverage), so the description doesn't need to add parameter semantics. The description adds no parameter-specific details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Submit') and resource ('debt collection case to Debitura'), and clearly distinguishes it from siblings by framing it as a 'LEGAL AND FINANCIAL ACTION' that starts recovery, unlike preview_case. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mandates a required workflow: 'Call preview_case first', 'Ask the user to explicitly confirm submission', and 'NEVER call it without the user's explicit confirmation'. This explicitly states when to use it versus the preview sibling and sets a clear precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a count of cases per lifecycle stage for the creditor's account. Useful for a quick portfolio overview without listing all cases. Stages: PendingContractSigning, PendingVerificationInternal, PendingVerification, NeedsAdditionalDetails, Leads, LeadsQuoteGiven, Active, Paused, Closed, Merged. Note: these counts include the creditor's own test cases; list_cases exposes the isTestCase flag that marks them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, not destructive), description adds behavioral context: it includes test cases, lists all stages, and relates to list_cases. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, followed by usage context, list of stages, and a note about test cases. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, stages, and test case inclusion, but lacks explicit output format or structure. Since there is no output schema, a brief mention of the return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so description carries full burden. It adds meaning by detailing what the tool returns (counts per stage) and listing the stages, which is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a count of cases per lifecycle stage for the creditor's account. It distinguishes itself from sibling list_cases by noting it's a quick overview without listing all cases, and explicitly mentions list_cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('quick portfolio overview') and when not ('without listing all cases') and provides an alternative tool (list_cases) for detailed access including test case flag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one collection case in full detail. Look it up by Debitura case ID (GUID), by your own creditor reference (e.g. invoice number), or by the Debitura case reference shown in the portal. Provide exactly one of the three identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Debitura case ID (GUID) | |
| caseReference | No | Debitura case reference as shown in the portal | |
| creditorReference | No | Your own reference for the case (e.g. invoice number) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds minimal behavioral context beyond stating it returns full detail. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: first states purpose, second states usage constraint. Every sentence is necessary and front-loaded with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain what 'full detail' includes, leaving the return structure undefined. The tool is simple but could be improved by noting that it returns all case fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description adds critical constraint 'Provide exactly one of the three identifiers', which the schema does not enforce, thus adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches one collection case in full detail, specifying the resource and verb. It distinguishes from sibling tools like get_case_activity or get_case_payments by implying it returns the complete case rather than a subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to provide exactly one of the three identifiers, which is clear usage guidance. However, it lacks explicit when-to-use vs alternatives, though the sibling names imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the chronological timeline of a case — what has happened so far: status changes, partner actions, communications, and payments. Returns an envelope { items, currentEngagementPhase }: items is the chronological event list, and currentEngagementPhase is the case's current engagement phase ("Pre-legal", "Legal", or "Enforcement"; null when no active engagement exists).
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | Debitura case ID (GUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the return structure (envelope with items and currentEngagementPhase) with possible values, providing behavioral context beyond safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first defines the purpose, second explains the return shape. No unnecessary words, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description fully explains the tool's behavior and return structure, including possible values for currentEngagementPhase. It is complete given the lack of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (caseId described as 'Debitura case ID (GUID)'). The tool description does not add additional parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'chronological timeline of a case', listing specific event types (status changes, partner actions, communications, payments). This distinguishes it from sibling tools like get_case_messages or get_case_payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool returns (case timeline), but does not explicitly provide when-to-use or when-not-to-use conditions or name direct alternatives. However, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check which contracts (e.g. debt collection agreement, power of attorney) are signed or still blocking a case, including signing URLs for any outstanding documents.
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | Debitura case ID (GUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that signing URLs are returned for outstanding documents, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return values (signed/blocking contracts, signing URLs). Could mention scope is per caseId but implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for caseId. Description does not add additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states specific verb 'Check' and resource 'contracts signed or still blocking a case', distinguishing it from siblings which deal with other case aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for checking contract status, but no explicit when-to-use, when-not-to-use, or alternative tools provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the chat conversation on a case between you and the collection partner handling it. Each message includes: senderName, role (Creditor / Partner / Managed by partner), sentAt (UTC), message. See the debitura://glossary/chat-roles resource for what each role means.
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | Debitura case ID (GUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about the conversation parties, message fields, and a glossary reference, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose, second lists message fields and provides a helpful link to a glossary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description compensates by listing message fields and referencing roles, but could optionally mention pagination or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'caseId' described adequately. The description does not add additional parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Read the chat conversation' as a specific verb+resource, clearly distinguishing it from write tools like 'send_case_message' and other case-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use ('to read chat conversation') but does not explicitly mention when not to use or alternatives, though sibling tools make this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every payment recorded on a case — money recovered so far.
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | Debitura case ID (GUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds minimal behavioral context ('money recovered so far'), but does not explain pagination, ordering, or what constitutes 'every payment'. Acceptable given the safety profile from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that front-loads the purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers the core functionality. However, it omits potential details like whether results are paginated or ordered, but given the tool's simplicity and annotations, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description does not add any extra meaning to the caseId parameter beyond what the schema already provides (a UUID). No elaboration on format or usage tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('every payment recorded on a case'), with a clarifying note about money recovered. It distinguishes from siblings like get_case or get_case_activity by focusing specifically on payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool. With siblings like get_case_activity or get_case, the description does not explain how this tool fits in or when to choose it over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the open tasks (action-items) attached to one specific case — same data as list_tasks, scoped to a single case. Use this when you're already working a specific case and want just its outstanding tasks.
Note: account-level tasks that aren't tied to any one case (e.g. SignContract, AssignBankAccount — these block the whole account, not one case) never appear here; use list_tasks to see those.
See list_tasks for the full task model (auto-resolve, solutionUrl, action).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to specific task types, e.g. ["ReplyToChat", "SignContract"]. Valid values: Generic, ReplyToChat, SelectQuoteWinner, ReviewPartner, ClientInputRequired, SignContract, MoreInfoNeeded, AssignBankAccount, CaseValidationNeedsInfo | |
| caseId | Yes | Debitura case ID (GUID) | |
| status | No | Filter by task status. "Open" (default) or "Solved". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: explains that account-level tasks are excluded and references list_tasks for the full task model, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and includes necessary clarifications in a note without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full input schema coverage, no output schema, and annotations indicating a safe read operation, the description fully covers the tool's behavior, constraints, and relationship to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond what the schema provides. It does imply default status 'Open' and mentions type filtering, but these are already in parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists open tasks for one specific case, uses the verb 'list' with the resource 'tasks', and distinguishes from the sibling 'list_tasks' by noting scoping and exceptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you're already working a specific case') and when not to (account-level tasks not here, use list_tasks). Names alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all documents attached to a case: file name, document type, description, upload date, and a time-limited SAS download URL. Each file also carries downloadUrlExpiresAt (UTC) — when the download URL stops working, so a cached URL can be refreshed in time. Use upload_case_file to attach new documents.
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | Debitura case ID (GUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral details like time-limited SAS URLs and downloadUrlExpiresAt for cache refresh, which adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient and front-loaded. Includes purpose, key details, and sibling reference without redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, clear annotations, no output schema), the description covers return fields, caching behavior, and attachment option, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (caseId already well-described). Tool description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all documents attached to a case' with specific fields, and distinguishes from sibling 'upload_case_file' by referencing it explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for usage and mentions alternative tool (upload_case_file), but does not explicitly state when not to use or exclude other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the creditor's debt collection cases with pagination, status filtering, and sorting. Returns compact case summaries: reference, debtor name + country, amounts, lifecycle, partner, key dates. Use get_case for full detail on a specific case.
Lifecycle values (statuses filter and output):
PendingContractSigning · PendingVerificationInternal · PendingVerification · NeedsAdditionalDetails · Leads · LeadsQuoteGiven · Active · Paused · Closed · Merged
Sortable fields: DateCreated · DateUpdated · DateFinished · DateCollectionStarted · DueDate · Date · GrossAmount · Remainder · InterestFees · CollectionFees
Sort format: Field:asc or Field:desc, e.g. GrossAmount:desc
Note: results include the creditor's own test cases; the isTestCase flag on each case marks them.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting from 1 (default 1) | |
| sort | No | Sort expression: Field:asc or Field:desc. Valid fields: DateCreated, DateUpdated, DateFinished, DateCollectionStarted, DueDate, Date, GrossAmount, Remainder, InterestFees, CollectionFees. Example: GrossAmount:desc | |
| pageSize | No | Results per page (default 10, max 100) | |
| statuses | No | Filter by lifecycle status. Values: PendingContractSigning, PendingVerificationInternal, PendingVerification, NeedsAdditionalDetails, Leads, LeadsQuoteGiven, Active, Paused, Closed, Merged |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds that it returns compact summaries and includes test cases marked by isTestCase, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a concise first sentence, followed by detailed bullet points. No unnecessary words, each sentence adds unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, it describes return fields and the isTestCase flag. Covers pagination, filtering, sorting, and a note about test cases. Complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description lists parameters and explains sort format and enum values, adding minor value over schema. No major shortcomings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists debt collection cases with pagination, status filtering, and sorting. It specifies the resource and actions, and distinguishes itself from get_case for full detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions using get_case for full details, implying list_cases for summaries. It also details filtering and sorting. However, it could more explicitly state when not to use it (e.g., for creation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every open task (action-item) across your whole account — things the platform needs you to do before a case (or your account) can proceed: reply to a chat, sign a contract, assign a bank account, and so on. Use get_case_tasks instead to scope this to one case.
Tasks auto-resolve once the underlying condition clears — e.g. replying to a case's chat makes its ReplyToChat task disappear on its own. Treat this as a live work queue, not a log: a task seen on one call may no longer be open on the next.
Every task carries a solutionUrl — an absolute link a human can open to resolve it in one click, whatever the type. Some types (today: ReplyToChat, ClientInputRequired, MoreInfoNeeded) additionally carry a non-null action pointing at the exact API call that resolves them — for those, call send_case_message with the task's caseId instead of sending a human to solutionUrl. Tasks without an action rely on solutionUrl alone.
Task types: Generic, ReplyToChat, SelectQuoteWinner, ReviewPartner, ClientInputRequired, SignContract, MoreInfoNeeded, AssignBankAccount, CaseValidationNeedsInfo.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting from 1 (default 1) | |
| type | No | Restrict to specific task types, e.g. ["ReplyToChat", "SignContract"]. Valid values: Generic, ReplyToChat, SelectQuoteWinner, ReviewPartner, ClientInputRequired, SignContract, MoreInfoNeeded, AssignBankAccount, CaseValidationNeedsInfo | |
| status | No | Filter by task status. "Open" (default) or "Solved". | |
| pageSize | No | Results per page (default 10, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent; description adds key behaviors: auto-resolution, solutionUrl usage, action field for certain types, and instructions to call send_case_message for those types. Fully transparent beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: starts with purpose, then differentiation, then behavioral details, and ends with type list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully explains return values (solutionUrl, action), task behavior, and how to resolve tasks. Pagination is handled via parameters. Complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. Description does not add additional meaning beyond listing allowed types, which are already enumerated in schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists every open task across the whole account. It contrasts with sibling tool get_case_tasks, which scopes to one case. Verb 'list' and resource 'tasks' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use get_case_tasks instead for case-scoped tasks. Describes tasks as a live work queue, not a log, guiding appropriate usage. No misleading statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the team members on the creditor's Debitura account. Use this to resolve a valid sender (userId or email) before calling send_case_message, or a case owner for create_case.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| pageSize | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the behavioral context of resolving user IDs/emails, which is useful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Purpose and usage are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers the tool's purpose and usage, but lacks any hint about the output structure (e.g., fields returned). Still, for a simple listing tool with annotations, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra meaning beyond what the schema already provides for 'page' and 'pageSize'. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'team members on the creditor's Debitura account', and distinguishes its purpose from siblings by noting its use to resolve a sender or case owner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'before calling send_case_message, or a case owner for create_case', providing clear context and practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the connection to Debitura and show which creditor account the API key belongs to. Call this first to confirm the integration is set up correctly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds that it reveals the creditor account, which is useful context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully explains purpose and usage context. Annotations cover safety. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is trivially 100%. Baseline 4 applies as no parameter documentation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it verifies the connection and shows the creditor account. Distinguishes from all sibling tools which handle cases, files, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this first to confirm the integration is set up correctly.' Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dry-run a collection case BEFORE creating it: returns eligibility, the assigned collection partner, pricing (success fee), and any contracts that would need signing. Nothing is persisted. ALWAYS call this before create_case and show the user the pricing and requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| dueDate | No | Invoice due date (ISO 8601) — used to compute debt age for pricing | |
| claimLines | No | Unpaid invoices making up the claim. Use instead of amountToRecover and age buckets; Debitura derives the total and aging. | |
| debtorType | Yes | Company (B2B) or Private individual (B2C) | |
| currencyCode | Yes | ISO 4217 currency code, e.g. "EUR", "USD", "DKK" | |
| amountToRecover | No | Total principal amount. Omit when sending claimLines | |
| debtorStateAlpha2 | No | US state code, e.g. "CA" — REQUIRED when the debtor is in the United States | |
| debtorCountryAlpha2 | Yes | Debtor country, ISO 3166-1 alpha-2, e.g. "DE", "US" | |
| amountToRecoverOver6Months | No | Cumulative principal more than 180 days overdue | |
| amountToRecoverOver12Months | No | Cumulative principal more than 365 days overdue | |
| amountToRecoverOver24Months | No | Cumulative principal more than 730 days overdue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds context by stating 'Nothing is persisted' and enumerates the return payload (eligibility, partner, pricing, contracts). This goes beyond the annotations and clarifies the operation's safe, consultative nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action ('Dry-run... BEFORE creating it'), followed by return values and a usage directive. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description provides a good overview of the returned information and a clear call-to-action. It does not detail error cases or edge conditions, but given the annotations and schema richness, it is sufficiently complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 10 parameters. The description does not add additional parameter-specific semantics beyond noting that pricing and eligibility are computed from the input, but this is implied rather than explicit. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Dry-run a collection case'), the object (collection case), and the purpose (before creating it). It distinguishes from create_case by explicitly noting nothing is persisted, and lists the return values (eligibility, partner, pricing, contracts), making it distinct from get_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'ALWAYS call this before create_case' provides explicit usage context and an alternative (create_case). It also tells the agent to show the user the pricing and requirements, which is a clear workflow directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a chat message on a case to the collection partner handling it. The partner is notified by email. The message is attributed to a named team member, so a sender is REQUIRED: pass the sender's userId or email from list_team_members. Ask the user who the message should be sent as if it is not obvious.
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | Debitura case ID (GUID) | |
| message | Yes | The message to send | |
| senderEmail | No | Team member email sending the message (alternative to senderUserId) | |
| senderUserId | No | Team member ID sending the message (from list_team_members) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the 'destructiveHint' annotation, the description reveals that the partner is notified by email and the message is attributed to a named team member. These behaviors are not captured in annotations. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and every sentence adds unique value. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, behavioral effects (notification, attribution), parameter requirements and sourcing, and user interaction guidance. Given there is no output schema, the description is fully adequate for a send operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds meaning by specifying that senderEmail or senderUserId should come from 'list_team_members' and that one is required. It also advises to ask the user when the sender is not obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a chat message on a case to the collection partner, and it specifies the action ('send'), the resource ('case'), and additional details (notification by email, attribution). It distinguishes itself from siblings like 'get_case_messages' by focusing on sending rather than reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: the partner is notified, the message is attributed, and a sender is required. It references 'list_team_members' as a source for the sender. It also advises to ask the user if not obvious. However, it does not explicitly state when not to use this tool or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a document to a case (invoice copy, contract, correspondence, proof of delivery). Max 25 MB. Allowed extensions: .pdf, .xls, .xlsx, .csv, .txt, .jpg, .jpeg, .png, .gif. Provide the file content base64-encoded.
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | Debitura case ID (GUID) | |
| fileName | Yes | File name including extension, e.g. "invoice-1042.pdf" | |
| contentType | No | MIME type, e.g. "application/pdf" (inferred from extension if omitted) | |
| description | No | Short description of the document | |
| documentType | No | Document category (default: OriginalInvoice). Values: OriginalInvoice · DebtorDocuments · CreditorDocuments · PartnerDocuments · DemandLetter · Miscellaneous | |
| contentBase64 | Yes | File content, base64-encoded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true (modification). Description adds concrete behavioral details: file size limit, allowed extensions, and encoding requirement, which are not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence plus list of extensions and encoding hint. It is concise, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists; description does not mention return value (e.g., attachment ID). It covers input constraints well but omits post-upload behavior, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters described). Description adds overall context (base64, file types) but does not detail individual parameters beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: Attach a document to a case, with examples (invoice copy, contract, etc.). It distinguishes from siblings like list_case_files and get_case by focusing on upload/write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides constraints (max 25 MB, allowed extensions, base64 encoding) but does not explicitly say when to use vs alternatives. Context is clear enough for an upload tool among mostly read siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.
Incorporate globally, manage fundraising, corporate services, and more.
Free demand-letter PDF generator for unpaid invoices, 80+ jurisdictions, 29 languages.
Search 18M+ legal documents worldwide — case law, legislation, and doctrine across 110+ countries.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct resource and action: case vs. tasks vs. files vs. messages vs. payments vs. account summary. The get_case_* family is broken out by specific sub-resource (activity, contract status, messages, payments, tasks), and preview_case is explicitly distinguished from create_case. list_tasks vs. get_case_tasks are scoped differently and the descriptions call out the difference.
All tool names follow a consistent lowercase verb_noun pattern: create_, get_, list_, send_, upload_, preview_, ping. Even the standalone 'ping' is a common health-check convention and does not break the pattern. No camelCase or mixed verb styles appear.
At 16 tools, the server is slightly above the typical 3-15 well-scoped range, but the breadth of the domain (case lifecycle, tasks, files, messages, payments, team management) justifies each tool. The count feels reasonable rather than bloated, earning a 4 rather than a 5.
The core workflow is well covered: preview, create, monitor (list/get, activity, payments, messages, contract status, files, tasks), communicate, and attach files. Missing operations like update_case, delete_case, or explicit task resolution are gaps, but they are often not needed in this domain since tasks auto-resolve and the partner drives legal processes. Overall, the surface is complete enough for typical agent workflows.
