List the saved audiences/segments used for campaign targeting, each with its filter definition and campaign-usage count. Set includeCount: true to also resolve how many clients currently match each audience, and includePredefined: true to include built-in predefined segments. Read-only — use before comms_create_campaign to pick a target audience.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | ||
| orgSlug | Yes | ||
| includeCount | No | ||
| includePredefined | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the tool is read-only and explains the effect of both optional flags (resolving match counts, including predefined segments). Missing details like pagination or error behavior, but for a list tool this is adequate.
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 purpose, followed by flag explanations and usage guidance. No wasted words; every sentence 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?
Despite no output schema, the description specifies what each audience includes (filter definition, campaign-usage count) and what the includeCount flag adds. It could mention ordering or pagination, but it's reasonably complete for a list tool with 4 params and no annotations.
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 schema has 0% coverage and the description explains includeCount and includePredefined, but does not explain orgSlug (required) or apiKey. Since these are likely common context parameters, some clarity is missing; the description compensates only partially.
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 (saved audiences/segments used for campaign targeting), and adds specifics like filter definition and campaign-usage count. It distinguishes from sibling tools like comms_list_campaigns by focusing on audiences/segments.
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 'use before comms_create_campaign to pick a target audience', providing a concrete usage context and linking to a sibling tool. Also explains when to set includeCount and includePredefined flags.
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.