HeyLead

Overview Schema Source Related Servers Discussions Admin

contacts

Read-only

Search and browse contacts, view details, run LinkedIn keyword searches, and export data as table, CSV, or JSON—read-only, no changes made.

Instructions

Search, browse and read your contacts, and export them. Changes nothing.

Tagging, noting, re-staging and linking are update_contact.

Args:
    action: "list", "search", "view", "stats", "export", "linkedin_search"
        or "my_connections".
    query: Search text for "search", "linkedin_search" and "my_connections".
        For "linkedin_search" the query is passed to LinkedIn as KEYWORDS,
        matched literally — a company name, a job title, a person's name, or a
        combination such as 'Acme Corp CTO' or 'Jane Doe'. A natural-language
        question ('who is the CTO of Acme?') is sent through unchanged and
        usually comes back empty, so prefer keywords. Nothing is filtered out
        locally. An empty result and a failed search are reported in different
        words, so a "no matches" line means LinkedIn really returned nobody
        rather than "the search broke". Results are capped at 25 per call
        because every result costs a profile fetch and a LinkedIn read.
    contact_id: Which contact (view).
    lifecycle_stage: Filter by stage.
    min_fit_score: Only those scoring at least this.
    limit: How many.
    format: "table", "csv" or "json" (export).
    campaign_id: Filter by campaign.
    connected_since: Only those connected on or after this date.
    connected_before: Only those connected before this date.

Input Schema

TableJSON Schema

Name	Required	Default
`limit`	No
`query`	No
`action`	No	list
`format`	No	table
`contact_id`	No
`campaign_id`	No
`min_fit_score`	No
`connected_since`	No
`lifecycle_stage`	No
`connected_before`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.10.389Sep 21, 2026

removedInput schema / properties / dry_run

Removed value: -{
-  "default": true,
-  "title": "Dry Run",
-  "type": "boolean"
-}

removedInput schema / properties / match

Removed value: -{
-  "default": "name",
-  "title": "Match",
-  "type": "string"
-}

removedInput schema / properties / note

Removed value: -{
-  "default": "",
-  "title": "Note",
-  "type": "string"
-}

removedInput schema / properties / tag

Removed value: -{
-  "default": "",
-  "title": "Tag",
-  "type": "string"
-}

First observedv0.10.375Sep 18, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond readOnlyHint=true, the description discloses meaningful behavioral details: results are capped at 25 due to cost, nothing is filtered locally, and the distinction between 'no matches' and a failed search is explained. It also specifies that natural-language LinkedIn queries are passed through unchanged and usually return empty, which is critical for expected behavior.

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 front-loaded with the core purpose, then uses a clean 'Args:' block that maps directly to the schema. The longest section (query) earns its length by explaining the nuanced LinkedIn behavior. No sentences are filler.

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?

The tool is complete for an agent: it explains when to use it, what it does not do, parameter semantics, error-reporting nuance, rate limits, and output formats. An output schema is present, so return values need not be described. The sibling routing is explicit.

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?

With 0% schema description coverage, the description compensates fully: all 10 parameters are documented. The query parameter receives extra depth, including literal LinkedIn keyword matching, example formats, a warning about natural-language queries, and cap behavior—all meaning beyond the schema's type and default fields.

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 opens with a specific verb and resource: 'Search, browse and read your contacts, and export them.' It also explicitly declares 'Changes nothing' and names the sibling with mutating operations ('Tagging, noting, re-staging and linking are update_contact'), making the tool's scope unmistakable.

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

Usage Guidelines5/5

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

The description explicitly routes mutations to a sibling: 'Tagging, noting, re-staging and linking are update_contact.' The read-only context is reinforced with 'Changes nothing.' While it doesn't say 'use this when you need to read contacts,' the inclusion of the alternative and the clear non-mutating scope leaves no ambiguity.

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