Get the total number of unread conversations across all LinkedIn accounts in the workspace. Returns { total, accountCount } where total is the sum of unread conversation counts, accountCount is the number of active LinkedIn accounts in the workspace. Uses denormalized counters for efficiency (no conversation table scan).
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | No |
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 establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context: it returns a specific shape, defines accountCount as active accounts, and explains the use of denormalized counters for efficiency with no conversation table scan. This helps the agent understand performance and semantics beyond the 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 three sentences with no filler. The main action is front-loaded, the return contract is stated precisely in the second sentence, and the efficiency note in the third sentence is a useful, non-redundant addition. Every sentence earns its place.
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 return value is fully described even though no output schema exists, and the workspace-scoped aggregation is clear. For a simple, read-only counter tool with strong annotations and one obvious parameter, this is nearly complete; the only minor gap is explicit parameter-level guidance.
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 only one parameter, workspaceId, but no schema-level description (0% coverage), so the tool description carries the burden. The phrase 'in the workspace' connects the parameter to the count's scope but does not explicitly name workspaceId, explain its role, or clarify whether it is required. Partial compensation only.
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 opens with a specific verb and resource: 'Get the total number of unread conversations across all LinkedIn accounts in the workspace.' It clearly states the aggregated scope and distinguishes this aggregate-count tool from sibling tools like list_inbox_conversations or count_unread_notifications.
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 implied use case is clear: use this when the agent needs an aggregate unread-conversation count across all accounts rather than a list of conversations. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named to help disambiguate from nearby list/count tools.
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.
Many tools share the same verb prefix (create_, list_, update_, get_) across closely related resources, so pairs like add_lead_to_external_list vs add_lead_to_sequence, create_signal_agent vs create_signal_watch, and approve_review vs approve_content_post can be confused. The descriptions are unusually detailed and cross-referenced, which mitigates but does not eliminate the ambiguity inherent in a 282-tool surface.
Virtually every tool follows the campaignstack_verb_noun snake_case pattern, which is highly predictable. Minor deviations exist: destructive operations mix remove_ and delete_ (remove_lead_list vs delete_campaign), AI generation uses both craft_ and generate_, and the seo_/search_console_ subdomains introduce a second prefix convention.
282 tools is an extreme mismatch by any reasonable standard, exceeding the 50+ threshold by more than 5x. Even for a full B2B outreach platform, this surface is far too large and would be better consolidated into higher-level operations or grouped sub-servers.
The tool surface is impressively comprehensive, covering campaigns, workflows, leads, content, ads, SEO, integrations, billing, and more with CRUD-level depth. Minor gaps remain: no single-ICP getter, no direct pause/delete for search watches, and no explicit delete for ad campaigns (only archive via update).
