List contacts with their subscription status and engagement metrics. Filter by status to find unsubscribed or bounced addresses that should be excluded from sends.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| limit | No | Results per page (default 20, max 100) | |
| search | No | Search across email, name, and company | |
| status | No | Filter by subscription status |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that it returns subscription status and engagement metrics, which is useful context beyond annotations, but does not disclose pagination behavior or potential rate limits. This is acceptable given annotations.
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 purpose, and every sentence adds value. No fluff or 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?
For a simple list tool with good schema coverage and idempotent/readOnly annotations, the description covers the key aspects: what it returns, how to filter, and a practical use case. No output schema exists, but the description mentions the fields (subscription status, engagement metrics) which partially covers return info. It is slightly lacking in discussing pagination or total counts but that is addressed by schema parameters.
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?
All four parameters are fully documented in the schema (100% coverage), so the description adds little beyond the schema. The description does not elaborate on parameter usage, but the schema already includes descriptions for each. The baseline of 3 is appropriate because the description does not contradict or add much value.
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 lists contacts and includes specific details about subscription status and engagement metrics, which distinguishes it from generic list tools. It doesn't explicitly compare to siblings, but the context of filtering by status for unsubscribed/bounced addresses is specific enough.
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 a clear when-to-use context: 'Filter by status to find unsubscribed or bounced addresses that should be excluded from sends.' It does not mention alternatives but the sibling list is large and this tool is uniquely about contacts, so the guidance is adequate.
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 cleanly separated by resource and action, and the descriptions do a good job of cross-referencing related tools. However, there are several close clusters—get_analytics vs generate_report, get_deliverability_score vs run_deliverability_audit, check_dmarc vs verify_domain, and list_emails vs list_inbox_conversations vs get_email—that could cause an agent to pick the wrong one. The detailed descriptions reduce but do not eliminate this ambiguity.
Tool names follow a consistent snake_case verb_noun pattern throughout: create_, get_, list_, send_, toggle_, and so on. Even multi-word actions like select_ab_test_winner and categorize_inbox_emails stay uniform. The only slight deviation is the bare verb upgrade, but it is readable and does not break the overall pattern.
54 tools is far beyond the typical well-scoped MCP surface and lands heavily in the 'too many' range. While the domain is broad, many tools could be consolidated—multiple analytics/reporting tools, several deliverability checks, and separate email/inbox listing tools create redundancy. The sheer number increases selection overhead and makes the toolset harder for an agent to navigate reliably.
The core email marketing lifecycle is represented: domains, contacts, campaigns, templates, automations, sends, and analytics all have main operations. However, there are notable gaps—no update/delete for campaigns, templates, forms, or automations; no create/update/delete for forms; no sandbox enable/disable; and no way to install marketplace items. These are workable gaps but would cause failures for agents trying to perform full lifecycle management.