Skip to main content
Glama

Add People To The Do-Not-Contact List

li_suppress_profiles
Destructive

Add LinkedIn profiles to the do-not-contact list — people who asked not to be contacted, existing customers, competitors, anyone the team must never invite or message from here. The do-not-contact list is checked at IMPORT — a listed prospect is NOT imported and is reported by name in result.suppressed of li_ingest_prospects — and again at INVITE time, so a queued invite for someone added to the list after their import is retired with category suppressed instead of sent — and before every automated message step, and by the assistant send tools (li_send_reply, li_send_message, li_send_bulk_messages), which REFUSE a listed person. Only a message a person types themselves in LinkedIn or on the dashboard is not blocked. It is per TEAM: an entry made with a personal token applies to every LinkedIn account that team runs and to nobody else; entries on the INSTALL-WIDE list (made by the operator, i.e. the shared secret) apply to every team. Dry-run unless confirmSuppress=true: the preview returns exactly what the confirmed call WOULD add (wouldAdd), who is already on the list (alreadyListed) and what is not a profile URL at all (invalid), so the user can confirm the real change. The confirmed call returns the same three buckets as added / alreadyListed / invalid plus a one-line summary that names every count — relay it whole, including the invalid ones, or the user believes people are protected who are not. Adding someone does not withdraw an invite already sent or stop a sequence already running; use li_mark_stopped for a live sequence.

Input Schema

NameRequiredDescriptionDefault
scopeNoWhich list to write to. "mine" = this team only. "install" = EVERY team on this install, including other customers. Only an operator may choose; a personal token always writes its own team's list and this is ignored. Defaults to "install" for an operator, which is the wider of the two — check the dry run.
reasonNoWhy, in a few words (max 300 chars) — shown beside every refusal this entry causes, so write it for the colleague who reads it later.
profileUrlsYesLinkedIn profile URLs or bare /in/ slugs, max 500 per call. A longer list is REFUSED rather than trimmed — split it and call again. The same person in several spellings is one row.
confirmSuppressYesMust be true to write; false returns a dry-run preview of what would change

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true but the description goes far beyond: it maps every enforcement point (import, invite time, automated message steps, the three assistant send tools), the one exception (messages a human types), the per-team vs install-wide scope model, and the dry-run/confirm gate. This is the kind of context annotations cannot carry.

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

Conciseness4/5

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

Front-loaded with the purpose and the consequences; every sentence carries substantive information about enforcement or return shape. It is long and dashes/caps-laden, and the enforcement points could be compressed, but nothing is pure 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?

There is no output schema, so the description must explain returns — and it does precisely: the three dry-run buckets (wouldAdd/alreadyListed/invalid), the confirmed buckets (added/alreadyListed/invalid), and the summary line, with an instruction to relay it whole including invalid counts. An agent has everything needed to call and report correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description still reinforces semantics the schema states, notably the dry-run meaning of confirmSuppress and the consequence of scope defaulting to 'install' for operators ('the wider of the two — check the dry run'), plus the 500-URL refusal 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?

States a specific verb+resource ('Add LinkedIn profiles to the do-not-contact list') and immediately enumerates the populations it is for. It is trivially distinguishable from siblings like li_list_suppressed and li_unsuppress_profile.

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?

Gives explicit when-to-use categories (asked not to be contacted, existing customers, competitors) and an explicit boundary — 'Adding someone does not withdraw an invite already sent or stop a sequence already running; use li_mark_stopped for a live sequence.' That is a named alternative with the selecting condition.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources