This server has 2 tools with significant quality gaps. Both tools have descriptions, but they are minimal. The search-conversations tool has a reasonable schema with proper types and enums for operators, but lacks descriptions for nested properties and critical parameter relationships. The list-conversations-from-last-week tool is trivial (empty input object). Neither tool documents output schema structure. Error handling returns generic error text without recovery guidance. No tool uses structured output formatting or includes pagination guidance despite returning conversation lists. Parameter descriptions exist but are sparse, e.g., 'Operator for created_at comparison' doesn't explain valid ranges or dependency between nested 'operator' and 'value' fields. The codebase shows basic validation via Zod but no attempt to guide LLMs on when to use each tool or how they chain together.
Fetch all conversations from the last week (last 7 days)
Search Intercom conversations with filters for created_at, updated_at, source type, state, open, and read status
Output schemas are not documented. Both tools return z.any() with no description of response structure, field types, or pagination. LLMs cannot plan downstream calls or extract needed data.
list-conversations-from-last-week has an empty input schema (z.object({})) and minimal description. This tool appears to have no configurable behavior (no pagination, no date range override, no filters). If truly trivial, it should be removed or expanded; if intentional, the description must explain why no parameters exist.
Nested object parameters (createdAt, updatedAt) lack descriptions for their nested 'operator' and 'value' fields. The schema shows enums for operator (=, !=, <, >), but the description does not explain dependency: 'operator' without 'value' is incomplete. This violates param-relationships pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
No pagination parameters (limit, offset, page, cursor) on search-conversations despite returning a list of conversations. Large result sets will exhaust context. Description does not mention result caps or pagination support.
Error responses are generic text ('Error: <message>') with no recovery guidance. When a filter is invalid or search fails, the LLM learns nothing about why or what to try next. Violates recovery-guide pattern.
Parameter descriptions are too brief and lack examples or constraints. E.g., sourceType is described as 'Source type of the conversation (e.g., "email", "chat")', the examples should be an enum, and the description should state 'Must be one of: email, chat, ...' or provide a discovery tool.
Tool names do not clearly signal scope difference. 'search-conversations' accepts many filters; 'list-conversations-from-last-week' is a narrow variant. An LLM cannot easily infer when to choose one over the other without extensive reasoning. Consider renaming to clarify intent.
Tool descriptions do not explain ordering, what fields are returned, or whether results are de-duplicated. 'Search Intercom conversations...' is functional but does not guide LLM selection or data extraction.