Skip to main content
Glama

network

Destructive

Access a reciprocal pool of LinkedIn connections to enrich profiles, find contacts, search prospects, and analyze message insights across member accounts.

Instructions

Network Intelligence — a reciprocal pool of members' connected accounts.

Pool members lend each other their LinkedIn accounts as "network sensors"
for enrichment, search, network analysis, and anonymized message insights.

The pool is reciprocal: it lends other members' connections and seats only
to a workspace whose own LinkedIn seat is an active member. The nine
consuming actions below are marked "members only" and are refused until
you join; joining is free and takes two calls — `opt_in`, then `sync`.
`status` reports whether you are opted in. The same is true of pooled
Premium/Sales Navigator seats used for search elsewhere in HeyLead: a
non-member is not lent one and quietly falls back to its own seat.

Args:
    action: What to do:
        "status"     — Pool health, member accounts, your participation
        "opt_in"     — Join the network pool (share your connections; this is what unlocks the members-only actions)
        "opt_out"    — Leave the network pool (also ends your access to it)
        "sync"       — Refresh your connection graph snapshot
        "opt_in_all" — Admin: opt in all connected LinkedIn accounts
        "sync_all"   — Admin: sync connections for all pool accounts
        "enrich"     — Members only: smart profile lookup via closest-connected pool account
        "contact"    — Members only: get email/phone via a 1st-degree connected pool account
        "parallel"   — Members only: enrich up to 100 profiles in parallel across pool
        "search"     — Members only: distributed search across pool (merged, deduplicated)
        "reach"      — Members only: show which pool accounts can reach a prospect
        "intros"     — Members only: find warm introduction paths to a prospect
        "insights"   — Members only: query aggregated message insights (objections, trends, patterns)
        "trends"     — Members only: industry trend analysis from cross-account conversations
        "patterns"   — Members only: objection and response patterns with timing data
    linkedin_id: Target prospect's LinkedIn provider_id (for enrich/contact/reach/intros).
    linkedin_ids: Comma-separated LinkedIn IDs (for parallel action).
    query: Search keywords (for search action).
    title: Job title filter (for search action).
    max_accounts: Max pool accounts to use for search (default 5).
    force_refresh: Ignore cache for enrich (default False).
    insight_type: Filter insights by type (for insights/patterns actions).
    segment: Filter by industry:seniority segment (for insights/trends actions).
    min_confidence: Minimum confidence threshold 0.0-1.0 (for insights action).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo
titleNo
actionNostatus
segmentNo
linkedin_idNo
insight_typeNo
linkedin_idsNo
max_accountsNo
force_refreshNo
min_confidenceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.375

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses reciprocity requirements, membership gating, refusal of members-only actions, the consequence of opt_out, admin-only capabilities, and the fallback to the workspace's own seat. These details go well beyond the annotations and explain how the tool's side effects and access constraints actually manifest.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but it earns its length: the concept is front-loaded, the action list is organized, and each argument is tied to specific actions. It avoids filler while covering a genuinely complex 15-action, 10-parameter API surface.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Together with the existing output schema, the description provides everything an agent needs to decide membership status, join/leave the pool, and invoke the correct members-only action with the right parameters. Edge behaviors like non-member fallback to the workspace's own seat are also covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description's Args section fully compensates by explaining all 10 parameters, enumerating every action value, and adding useful format details such as comma-separated LinkedIn IDs, industry:seniority segments, confidence range 0.0-1.0, and cache-refresh behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines this as an action dispatcher over a reciprocal LinkedIn network pool, with a precise list of 15 actions spanning membership, admin, and members-only intelligence operations. It goes far beyond the generic tool name and establishes a distinct resource that no sibling appears to duplicate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong usage context: members-only actions are refused until joining, joining requires opt_in then sync, and status reports participation. It does not explicitly name sibling alternatives, but the action-level guidance and membership precondition are clear enough for an agent to know when and how to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.