Skip to main content
Glama

Nilyo

by com.nilyo
OverviewDiscussionsAdmin

LinkedIn: Start conversation from inbox

linkedin_start_conversation_from_inbox
Destructive

Start a LinkedIn Classic, Sales Navigator or Recruiter conversation from an explicit inbox. Resolve recipient user IDs first and obtain inbox_id with linkedin_list_inboxes. For Sales Navigator include the required subject in specifics; Recruiter may require subject and signature. Supports one-to-one or group recipients and attachments.

Input Schema

NameRequiredDescriptionDefault
nameNo
textYes
inbox_idYesExact LinkedIn inbox ID returned by linkedin_list_inboxes. Preserve Classic/Sales Navigator/Recruiter selection; never pass contract_id or product name. Inbox ID: Provider inbox/product inbox identifier. LinkedIn Classic may use CLASSIC; premium products expose their own inbox IDs. Obtain with: linkedin_list_inboxes -> inbox.id Never pass: contract_id unless returned as the inbox id, guessing SALES_NAVIGATOR or RECRUITER.
specificsNo
users_idsYesOne exact provider user ID for a direct chat, or exact provider user IDs for a group; resolve every recipient first.
account_idNoOptional Nilyo connection ID (unipile_account_id from list_connected_accounts). Omit when the user has one account for this provider. When several exist, Nilyo never guesses: list them (display name, identifier, provider user ID), choose the one the user named or ask, and pass its ID here.
attachmentsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / users_ids / anyOf
      Previous value: -[
-  {
-    "description": "Exact provider user ID returned by the relevant profile/contact resolver; never a display name or profile URL. For LinkedIn, use the stable system ID. LinkedIn system user ID: Stable LinkedIn/Unipile user id, commonly ACo... for Classic profiles. Obtain with: linkedin_get_profile_from_url(profile_url) -> result.id; linkedin_get_profile(user_id_or_public_identifier) -> result.id; linkedin_search_people(...) -> selected result.id Never pass: full linkedin.com/in/... URL, person name, company ID.",
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "items": {
-      "description": "Exact provider user ID returned by the relevant profile/contact resolver; never a display name or profile URL. For LinkedIn, use the stable system ID. LinkedIn system user ID: Stable LinkedIn/Unipile user id, commonly ACo... for Classic profiles. Obtain with: linkedin_get_profile_from_url(profile_url) -> result.id; linkedin_get_profile(user_id_or_public_identifier) -> result.id; linkedin_search_people(...) -> selected result.id Never pass: full linkedin.com/in/... URL, person name, company ID.",
-      "minLength": 1,
-      "type": "string"
-    },
-    "minItems": 1,
-    "type": "array"
-  }
-]New value: +[
+  {
+    "description": "Exact provider user ID returned by the relevant profile/contact resolver; never a display name or profile URL. For LinkedIn, use the stable system ID. LinkedIn system user ID: Stable LinkedIn user id, commonly ACo... for Classic profiles. Obtain with: linkedin_get_profile_from_url(profile_url) -> result.id; linkedin_get_profile(user_id_or_public_identifier) -> result.id; linkedin_search_people(...) -> selected result.id Never pass: full linkedin.com/in/... URL, person name, company ID.",
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "items": {
+      "description": "Exact provider user ID returned by the relevant profile/contact resolver; never a display name or profile URL. For LinkedIn, use the stable system ID. LinkedIn system user ID: Stable LinkedIn user id, commonly ACo... for Classic profiles. Obtain with: linkedin_get_profile_from_url(profile_url) -> result.id; linkedin_get_profile(user_id_or_public_identifier) -> result.id; linkedin_search_people(...) -> selected result.id Never pass: full linkedin.com/in/... URL, person name, company ID.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "minItems": 1,
+    "type": "array"
+  }
+]
  2. First observed

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds product-conditional requirements and the prerequisite ordering, but says nothing about failure behavior, limits, or what sending actually commits (e.g. real outbound message to recipients).

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?

Three dense sentences, front-loaded with the action and scope, then prerequisites, then surface-specific rules. Little waste, though the multi-clause prerequisite sentence packs several distinct rules together.

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

Completeness4/5

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

For a mutation tool with no output schema and a nested-parameter schema at 43% coverage, the description covers the product variants, recipient resolution, inbox sourcing, and product-specific required fields. Remaining gaps (return value, attachment semantics, idempotency) are minor given the annotations are present.

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

Parameters3/5

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

Schema coverage is only 43% and `specifics` is an undocumented free-form object, so the description does meaningful work by noting the subject goes in specifics for Sales Navigator and that users_ids accepts one ID (direct) or many (group). This partially compensates for the gap but leaves several parameters (name, specifics structure, send_mode/voice_note) unexplained.

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 and resource ("Start a LinkedIn ... conversation") and scopes it to "from an explicit inbox", which distinguishes it from the sibling linkedin_start_conversation. It also enumerates the three supported product surfaces (Classic, Sales Navigator, Recruiter), so an agent can identify it without opening the schema.

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?

Gives concrete prerequisites: resolve recipient user IDs first and obtain inbox_id via linkedin_list_inboxes, plus product-specific requirements (Sales Navigator subject in specifics; Recruiter may need subject and signature). It stops short of explicitly contrasting when to choose this tool over linkedin_start_conversation or linkedin_send_message, so no exclusions are named.

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

All Nilyo toolsInspect
Try in Browser
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources