Find contacts with birthdays coming up within a time window or in a specific month. Returns contacts sorted by soonest birthday first, with age calculations when available.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Optional: show all birthdays in a specific month (1-12) instead of using days_ahead | |
| days_ahead | No | Look-ahead window in days from today (default: 30). Ignored if month is provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable details: 'Returns contacts sorted by soonest birthday first, with age calculations when available.' This explains sorting and return behavior. However, it does not disclose the precedence rule when both month and days_ahead are provided (though the schema does). Given no annotations, this is a strong behavioral description but not exhaustive.
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 with no redundant or irrelevant information. It front-loads the primary purpose and then adds key behavioral details (sorting, age). Every word earns its place, and it is appropriately sized for the tool's simplicity.
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 there is no output schema and no annotations, the description must convey return behavior, which it does ('Returns contacts sorted... with age calculations'). It covers the main use cases (time window or month) and the key output aspect. It could be more complete by mentioning what happens in edge cases (e.g., contacts without birthdays), but for a simple query tool, 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 the baseline is 3. The description's phrase 'time window' and 'specific month' paraphrases the parameter meanings but adds no additional semantic detail beyond what the schema already provides. The default value for days_ahead (30) is only in the schema, not the description. Thus, the description neither improves nor detracts from parameter clarity.
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 function: 'Find contacts with birthdays coming up within a time window or in a specific month.' This uses a specific verb (Find), a clear resource (contacts), and a distinguishing scope (birthdays within a time window/month). It also differentiates from sibling tools like contact_list and upcoming_reminders by focusing specifically on birthdays.
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 when to use the tool: when you need contacts with upcoming birthdays, either within a date range or for a specific month. It provides clear context but does not explicitly mention alternatives or when not to use it. For example, it doesn't say 'use contact_list for all contacts' or 'use upcoming_reminders for reminders.' This is clear usage context without explicit exclusions.
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.
Most tools are clearly distinct by entity, but contact_get and contact_timeline overlap significantly, and debt_manage's action='list' duplicates what other entities do with a dedicated list tool. Descriptions are detailed enough to resolve most ambiguity, though.
Tool names are mostly snake_case and readable, but they mix conventions: noun_verb (contact_create), verb_noun (batch_create_activities), and descriptive phrases (contacts_needing_attention). The noun_manage pattern is dominant, but the lack of uniformity makes the naming less predictable.
With 42 tools, the surface is very large, even for a full-featured CRM. Many tools bundle multiple actions, but the sheer number forces an agent to consider many options, increasing selection difficulty and cognitive load.
The server provides comprehensive CRM coverage: contacts, activities, notes, tasks, reminders, gifts, debts, relationships, tags, custom fields, notifications, settings, and exports. It supports batch operations, duplicate detection, merge, and special queries, leaving few if any obvious gaps.