list_team_membersList 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.
Add one secure layer between your agents and this server.
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.