Reach MCP — LinkedIn for AI agents

archive_conversation

Idempotent

Archive or unarchive a LinkedIn conversation. Set archive=false to unarchive. conversation_linkedin_id is the conversation_id returned by list_conversations; with page_id, a conversation of that company page's inbox. Housekeeping in the classic inbox or, with page_id, a company page's inbox; reversible (archive=false). Not a delete, see delete_conversation.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "account_id": "<account_id>",
      "conversation_linkedin_id": "<conversation_linkedin_id>"
    },
    "name": "archive_conversation"
  }
}

Input Schema

Name	Required	Description
`archive`	No	True to archive, False to unarchive.
`page_id`	No	Act as this company page instead of the member: page_id (or vanity name) from list_managed_pages. The account must be an admin of the page with a role that allows the action. Omit to act as the member.
`account_id`	Yes	Reach id of the LinkedIn account to act on, from list_accounts.
`idempotency_key`	No	Optional. A key you choose (a UUID is fine) that names this exact call. If you retry with the same key and the same arguments, the first call's result is returned and nothing is done twice on LinkedIn. Reusing a key with different arguments is refused. Keys expire after 24 hours.
`conversation_linkedin_id`	Yes	Conversation (thread) id, as returned by list_conversations.

Output Schema

Name	Required	Description	Default
`archived`	No	Current archived state

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / page_id

Added value: +{
+  "description": "Act as this company page instead of the member: page_id (or vanity name) from list_managed_pages. The account must be an admin of the page with a role that allows the action. Omit to act as the member.",
+  "type": "string"
+}

First observedSep 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare non-destructive, non-read-only, idempotent behavior, so the description only needs to add operational context. It usefully states the action is reversible via archive=false and that scope shifts to a company page inbox when page_id is supplied. It doesn't mention idempotency keys or what the response contains, but the output schema covers the latter.

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 verb and the reversible flag, and the exclusion comes last where it is easy to catch. The inbox-scoping clause is stated twice in slightly different wording ("with page_id, a conversation of that company page's inbox" then "or, with page_id, a company page's inbox"), which is mild redundancy.

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?

For a targeted, reversible mutation with rich annotations and an output schema, the description covers direction, reversibility, non-destructiveness, alternative tools, and act-as-page scoping. Nothing an agent needs to invoke it correctly is missing.

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 100%, so the schema already documents archive, page_id, account_id, idempotency_key, and conversation_linkedin_id. The description mainly restates those (the archive=false semantics and the list_conversations lineage of conversation_linkedin_id), adding only a little beyond the structured 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?

Opens with a specific verb pair and resource ("Archive or unarchive a LinkedIn conversation") and immediately explains the flag that flips the direction. It is clearly distinguishable from siblings like delete_conversation and star_conversation.

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?

Explicitly frames the use case as "housekeeping", states the inverse operation (archive=false), and names the alternative tool with an exclusion: "Not a delete, see delete_conversation." It also clarifies the member-inbox vs page-inbox scoping via page_id.

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

All Reach MCP — LinkedIn for AI agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?