Get accounts receivable aging report: pending charges grouped by age buckets (0-7, 7-30, 30-90, 90+ days). Use to answer "who owes money" or "old debts" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| apiKey | No | ||
| cursor | No | ||
| orgSlug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's output structure (pending charges grouped by age buckets) but does not clarify read-only safety, return format, or pagination behavior. This is adequate for a read-only report but lacks explicit behavioral safeguards or side-effect disclosure.
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 and resource, then provides bucket details and usage context. Every sentence adds value, and there is no 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 tool has 4 parameters, no annotations, and no output schema. The description explains what the report contains but omits pagination behavior, return structure details, and parameter semantics. This is minimally adequate for a simple report tool, but not fully 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 0%, and the description does not explain any of the parameters (orgSlug, limit, apiKey, cursor). The schema provides names and types, but the agent must infer their meaning. The description adds no value beyond the schema for parameter understanding, so a low score is warranted.
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 ('Get') and names a clear resource ('accounts receivable aging report'), and it details the age buckets (0-7, 7-30, 30-90, 90+ days). This distinguishes it from sibling tools like finance_client_balance or finance_list_invoices, which are not aging-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?
The description explicitly states when to use the tool: 'Use to answer "who owes money" or "old debts" questions.' It provides a clear context without naming alternatives, which would merit a 5, but it still gives actionable guidance.
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.
Multiple parallel booking creation flows (booking_create, scheduling_book, public_booking_create) and session state transition tools (booking_update_status, lifecycle_transition) create ambiguity. While descriptions are detailed, an agent could easily select the wrong tool for a given task, especially with 111 tools to choose from.
Most tools follow a consistent domain_action pattern (e.g., client_create, service_update, comms_list_campaigns). Minor deviations include Spanish/English mixing (cierre_*, report_deuda_real) and a few noun-only names like org_summary, but the overall structure is predictable.
With 111 tools, the server is massively over-scoped for an MCP surface. Even for a broad service business domain, this exceeds reasonable limits and will overwhelm agents, making tool selection slower and more error-prone.
The tool surface is extremely thorough, covering org setup, services, providers, booking (internal/public/spec), finance, payroll, closing, disputes, clinical notes, treatment plans, and reporting. Gaps are rare and often intentional (e.g., no deliver via MCP, read-only treatment plans), so agents can complete most workflows end-to-end.