Cross-border debt collection from your AI assistant: check cases, read partner messages, get pricing, and submit new collection cases across 183 countries.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 16 of 16 tools scored. Lowest: 3.5/5.
Each tool targets a distinct resource or action—creation, preview, listing, detail, and case-specific sub-resources (activity, contracts, messages, payments, tasks, files). The potentially overlapping task tools (list_tasks vs get_case_tasks) are explicitly cross-referenced and scoped differently.
Consistent verb_noun pattern throughout: create_, get_, list_, send_, upload_, preview_. Case-specific reads use get_case_* suffix pattern, and ping is the only utility exception.
16 tools is slightly above the ideal 3-15 range, but each tool earns its place in a comprehensive case-management API; no redundant tools.
Core lifecycle is covered (preview, create, list, get, sub-resources, messaging, file upload). Minor gaps include no case update/withdraw and no direct resolution for task types like SelectQuoteWinner, but these are mostly platform-controlled or handled via solutionUrl.
create_caseCreate Collection CaseASubmit 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 directly contradicts the annotations: idempotentHint is false, but the description states 'Submission is idempotent' and describes safe retries without risk of duplicate cases. While it provides valuable context about legal/financial action and contract signing, this annotation contradiction is a serious consistency flaw, forcing the minimum score.
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 slightly longer than average but every sentence is purposeful. The numbered workflow improves readability, and the idempotency and 422-handling sections are concise and clearly structured. It earns a 4 for being well-organized despite its length.
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 tool's high complexity (16 params, nested objects, no output schema), the description covers the most critical operational context: legal/financial consequences, required workflow, idempotency safety, and 422 error payload meaning. It omits the success response structure, but this is a minor gap given the absence of an output schema.
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 has 100% description coverage and is very detailed, so the description adds little parameter-specific meaning. It references the need to show assigned partner and contracts from preview_case, which contextualizes allowPendingContracts and assignedUserEmail, but does not go beyond what the schema already explains. 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 'Submit a debt collection case to Debitura' with a specific verb and resource, and distinguishes it from preview_case by framing submission as the actual legal/financial action. The title and description together unambiguously identify the tool's unique role among siblings.
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 an explicit, numbered required workflow: call preview_case first, show the user pricing/partner/contracts, get explicit confirmation, and never call without confirmation. It also explains how to handle 422 responses as business rejections, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_summaryGet Account SummaryAReturn 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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that counts include test cases and points to list_cases for filtering, providing 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?
Three sentences, front-loaded with the main action. Every sentence serves a purpose: what it does, when to use, and a caveat about test cases.
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 adequately covers what is returned (counts per stage), includes an important note about test cases, and references a sibling tool for more detail.
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?
With no parameters, baseline is 4. The description adds value by listing the lifecycle stages, which clarifies the output scope.
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 states a specific verb ('Return') and resource ('count of cases per lifecycle stage'), clearly distinguishing it from sibling tools like list_cases by offering a quick overview.
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 it's useful for a quick portfolio overview without listing all cases, and mentions list_cases for filtering test cases. Lacks explicit when-not-to-use guidance but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_caseGet CaseAFetch 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, idempotentHint, and destructiveHint. The description adds behavioral context by specifying the identifier constraint and implying full detail output, which complements the annotations without 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, each with a clear purpose: first states the action, second details the lookup methods and constraint. No waste, highly efficient.
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 fetch tool with 3 optional-but-one-required parameters, the description is complete enough. It lacks details on the output structure, but 'in full detail' and absence of an output schema make this acceptable. Annotations cover safety and idempotency.
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 basic descriptions. The description adds significant value by explaining the three parameters as alternative identifiers and the constraint to provide exactly one, which is not evident from the schema alone.
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 'Fetch one collection case in full detail', specifying the verb and resource. It distinguishes from sibling tools like list_cases by emphasizing the retrieval of a single case and providing three distinct lookup methods.
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?
Description explicitly instructs to provide exactly one of the three identifiers, guiding usage. However, it does not explicitly state when not to use this tool or mention alternatives, though the constraint is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_activityGet Case ActivityAFetch 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 read-only, idempotent, non-destructive. Description adds value by detailing the return envelope structure (items, currentEngagementPhase) and the possible phase values. 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?
Two sentences: first states purpose, second describes return structure. No filler, front-loaded with key 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?
Despite no output schema, the description fully explains what is returned (envelope with items and currentEngagementPhase). For a read-only tool with one well-documented parameter, this is 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% with clear description and format for caseId. The description adds no parameter info beyond the schema, which is acceptable given the high coverage. No extra meaning provided.
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 fetches the chronological timeline of a case, listing specific event types (status changes, partner actions, communications, payments). Distinguishes from siblings by focusing on holistic activity rather than specific aspects like messages or 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?
Implicitly differentiates from sibling tools by describing the broad timeline content. No explicit when-not-to-use or alternatives, but the purpose is clear enough for an agent to decide if full activity history is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_contract_statusGet Case Contract StatusACheck 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 already provide readOnlyHint, destructiveHint, idempotentHint. The description adds value by revealing that the tool returns signing URLs for outstanding documents, which is behavioral context beyond what annotations specify. 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 a single sentence that is concise and front-loaded with the action. It gets straight to the point without unnecessary words, though it could be broken into bullet points for structure.
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, the description explains what is returned: contract signing status (signed/blocking) and URLs for outstanding documents. This is sufficient for a read-only status check tool. Missing details like error responses are not critical.
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%; the description of caseId in the schema already explains it is a required UUID. The description does not add any additional parameter semantics beyond implying that the caseId identifies the case.
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 'check' and the resource 'contracts' in the context of a case, specifying that it returns signing status and URLs for outstanding documents. This distinguishes it from siblings like get_case (case details) and get_case_activity (activity log).
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 implicitly tells when to use it: when you need to know contract signing status for a case. It does not explicitly state when not to use it or mention alternatives, but the context is sufficiently clear for the single purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_messagesGet Case MessagesARead 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?
The description aligns with annotations (readOnlyHint, idempotentHint, destructiveHint) and adds valuable context about the message structure (senderName, role, sentAt, message) and a link to glossary. 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 concise with two sentences and a reference, front-loading the action. No unnecessary words 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?
For a simple read operation with one parameter and annotations, the description fully covers what the tool does, including return fields. Output schema is missing but description compensates.
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 schema already describes caseId as 'Debitura case ID (GUID).' The description adds no additional parameter meaning beyond the schema, so 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 explicitly states 'Read the chat conversation on a case between you and the collection partner handling it', using a specific verb and resource. It clearly distinguishes from sibling tools like send_case_message (write) 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 clearly implies this tool is for reading messages, and the sibling send_case_message provides the alternative. However, it does not explicitly state when not to use this tool or provide direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_paymentsGet Case PaymentsAList 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 indicate this is a read-only, non-destructive, idempotent operation. The description adds 'money recovered so far', which provides some behavioral context but does not significantly expand 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 a single concise sentence that immediately conveys the tool's purpose, with no wasted words or unnecessary details.
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 tool's simplicity (1 parameter, no output schema), the description captures the core functionality but does not explain what fields are returned in the payment records. Some details about the return format are missing.
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% for the single parameter caseId. The description does not add any additional parameter semantics 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?
The description clearly states the verb 'list' and the resource 'payments on a case', and it distinguishes this tool from siblings by specifying 'payments', which is unique among sibling 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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention conditions, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_tasksGet Case TasksAList 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 indicate read-only, idempotent, non-destructive. The description adds useful context beyond annotations, such as the exclusion of account-level tasks and that it shows only case-specific tasks.
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, each earning its place: first states purpose and scope, second gives usage guidance, third references sibling for full task model. 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 filtered list tool with strong annotations and full schema, the description is complete. It explains the relationship to list_tasks and covers necessary context for correct selection.
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 schema already documents all parameters. The description does not add significant new meaning beyond what's in the schema, thus baseline score of 3.
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 open tasks (action-items) for a specific case and explicitly distinguishes it from list_tasks by saying 'same data as list_tasks, scoped to a single 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?
Provides explicit guidance: 'Use this when you're already working a specific case and want just its outstanding tasks.' Also notes when not to use (for account-level tasks, use list_tasks).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_case_filesList Case FilesAList 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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description aligns with. It adds valuable behavioral context: the download URL is time-limited and includes an expiry field, which helps the agent understand caching behavior.
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 concise sentences with no fluff. The first sentence summarizes the purpose and return data, the second adds an important behavioral detail, and the third directs to a sibling tool. It is front-loaded and efficient.
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 lacking an output schema, the description fully explains the return fields, including the downloadable URL and its expiry. The input is simple (caseId). It also references the upload sibling, making the context complete for agent usage.
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 single parameter caseId is fully described in the schema as a GUID. The description does not add further parameter details, but schema coverage is 100%, so the baseline applies. The description does not detract and is sufficient.
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 all documents attached to a case and enumerates the specific fields returned (file name, document type, description, upload date, SAS URL). It distinguishes from the sibling tool upload_case_file. The title and context reinforce this.
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 a clear alternative (upload_case_file to attach documents) and a usage note about refreshing the cached URL before expiry. It implies when to use this tool (to list documents) but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_casesList CasesAList 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 declare readOnlyHint=true and destructiveHint=false. Description adds valuable behavioral details: includes test cases flagged with isTestCase, lists lifecycle statuses and sortable fields, and notes pagination. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with main purpose first, then details. A bit verbose with repeated status/sort lists, but each sentence adds value. Could be slightly shorter, but not wasteful.
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 compensates by stating return fields ('reference, debtor name + country, amounts, lifecycle, partner, key dates'), pagination defaults, test case behavior, and filtering options. Fully adequate for agent understanding.
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 description repeats parameter info without adding new meaning. However, it reinforces the sort format and lists enum values, which is helpful but not essential. 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?
Clearly states 'list the creditor's debt collection cases with pagination, status filtering, and sorting' directly after the title. The verb 'list' and resource 'cases' are specific, and it distinguishes from sibling 'get_case' by noting 'Use get_case for full detail on a specific 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?
Provides explicit alternative: 'Use get_case for full detail on a specific case.' Also implies context of listing vs. detail, but does not explicitly state when not to use (e.g., for bulk operations) or other alternatives. Still clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tasksList TasksAList 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 declare readOnlyHint true, destructiveHint false, and idempotentHint true. The description adds behavioral details beyond annotations: tasks auto-resolve, treat as live work queue not a log, and explains the solutionUrl and action fields for resolution, including specific types that support API-based resolution.
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 clear paragraphs for purpose, scope alternative, behavior, and resolution details. It fronts the main purpose first. Slightly verbose but not overly so; each part adds 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?
Given the 4 parameters and no output schema, the description provides substantial context on behavior, task types, resolution methods, and relationship to sibling. It does not explicitly describe the return format, but mentions solutionUrl and action fields which likely appear in output. Adequately 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 has 100% coverage with descriptions for all 4 parameters. The description does not add new meaning to the parameters themselves, but provides context on how the 'type' filter relates to the task types listed. 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 tool lists all open tasks across the entire account, using specific verb 'List' and resource 'tasks'. It explicitly distinguishes itself from the sibling 'get_case_tasks' by noting the scope difference.
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 explicit guidance: when to use this tool (list all open tasks) and when to use the alternative 'get_case_tasks' for scoping to one case. Includes context on auto-resolution and live queue nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_team_membersList Team MembersAList 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 and idempotentHint as true, and destructiveHint as false. The description adds no additional behavioral context beyond the basic list action, such as pagination behavior or performance considerations.
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 extremely concise with two sentences: the first states the core function, and the second provides the actionable context. No unnecessary 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 that the tool has only 2 optional parameters, no output schema, and annotations fully cover safety, the description adequately explains the tool's role in the broader workflow and is complete for an AI agent to understand when to use it.
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 both parameters (page, pageSize) documented in the schema. The description does not add any extra meaning or usage details for these parameters, 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?
The description clearly states the verb 'List' and resource 'team members', and distinguishes its purpose from sibling tools like send_case_message and create_case by specifying its role in resolving valid 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?
The description provides explicit guidance on when to use this tool: before calling send_case_message to resolve a valid sender, or for create_case to resolve a case owner. This differentiates it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingTest ConnectionAVerify 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?
Description adds context beyond annotations: it reveals that the tool shows which creditor account the API key belongs to, enhancing understanding of its read-only and idempotent 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?
Two sentences, front-loaded with purpose and usage, zero waste. Every word adds 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?
Given zero parameters, no output schema, and simple action, the description fully covers what an agent needs: what it does and when to use it.
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 exist, so baseline is 4. Description adds no parameter info, but none needed. Schema coverage is 100%.
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 verifies connection and shows which creditor account the API key belongs to, using specific verb 'verify' and resource 'connection'. It distinguishes from sibling tools that handle cases and accounts.
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', providing clear when-to-use guidance and no ambiguity about its role as a health check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_casePreview Case (Pricing & Eligibility)ADry-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?
Even though annotations already declare readOnlyHint and idempotentHint, the description adds valuable behavioral context: 'Nothing is persisted' and what the tool returns (eligibility, partner, pricing, contracts). This goes beyond the structured 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, zero filler. The critical action ('Dry-run') leads, and the imperative instruction is direct. Every phrase adds 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?
For a 10-parameter tool, the description is compact but sufficient. It explains the output ('returns eligibility, pricing, contracts') and the no-persistence behavior, while the schema covers parameter details. It could mention parameter alternatives (claimLines vs. amountToRecover), but that's a minor gap.
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 baseline is 3. The description adds no parameter-specific semantics beyond what the schema already provides, which is acceptable given the schema's thoroughness.
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 ('Dry-run') and resource ('a collection case'), clearly stating what it returns (eligibility, assigned partner, pricing, contracts). It distinguishes from create_case by emphasizing 'BEFORE creating it' and 'Nothing is persisted.'
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?
It explicitly instructs 'ALWAYS call this before create_case' and tells the agent what to do with the results ('show the user the pricing and requirements'). This provides clear when-to-use guidance and implicitly contrasts with the create flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_case_messageSend Case MessageASend 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?
Goes beyond destructiveHint=true annotation by detailing that the partner is notified and message is attributed to a team member. 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?
Two sentences: first states purpose and outcome, second provides essential usage instructions. No wasted words, 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 all aspects for a message-sending tool: action, required parameters, sender requirement, recipient notification. References sibling tool for parameter source.
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 3. Description adds extra value by explaining sender parameters (userId/email from list_team_members) and reinforcing caseId as GUID.
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?
Explicitly states action (send), resource (chat message on a case), and recipient (collection partner). Distinguishes from siblings like get_case_messages (retrieving messages) and create_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?
Provides clear when-to-use context, including partner notification by email. Gives critical instruction that sender is required and how to obtain via list_team_members. Advises agent to ask user if sender is not obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_case_fileUpload Case FileAAttach 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, which the description does not contradict. The description adds file size and extension restrictions but does not explain other behavioral traits (e.g., whether duplicate filenames are handled, if the file replaces an existing one).
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 concise sentences, front-loaded with purpose, followed by constraints. No fluff, every sentence adds necessary 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?
The description covers purpose and constraints adequately but does not mention the return value or success/failure behavior. Given no output schema, the agent might benefit from knowing what is returned (e.g., the file ID or confirmation).
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?
With 100% schema coverage, baseline is 3. The description adds value beyond the schema by specifying the 25 MB size limit and listing allowed extensions, which are not in the schema fields. It reinforces the base64 encoding requirement.
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's purpose: 'Attach a document to a case' with specific examples like invoice copy, contract, etc. It uses a specific verb-resource pair and is distinct from sibling tools (e.g., list_case_files).
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 includes explicit constraints (max 25 MB, allowed extensions, base64 encoding) that guide usage. It does not explicitly mention when not to use or name alternatives, but the context makes it clear this is the sole upload tool.
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
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!
