Skip to main content
Glama

sync_conversation

Loads this person's earlier message history (st.syncConversation action). Call once per person; repeating it within 24 hours returns quickly. Do not call it to check for new messages – use get_inbox. After it completes, read the history with get_inbox and personUrl.

Linked API actions are queued into a cloud-browser workflow and may take several minutes. The server returns immediately after starting the workflow with {status: 'pending'|'running', pendingReason, workflowId, operationName, message}. To retrieve the final result, call get_workflow_result with the returned workflowId and operationName — it will long-poll until completion or the request budget elapses, then return either the final result or another in-progress snapshot. Do not retry the original tool while a workflow is still running; that creates duplicate queued work.

A pending workflow carries pendingReason: 'queued' means it is waiting its turn behind other work on the same account and will start within minutes. 'outsideWorkingHours' means the account has configured working hours and the workflow is parked until they reopen — possibly the next working day. In that case get_workflow_result returns immediately instead of polling, message states when the window opens, and you should report that to the user rather than looping.

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": {
      "personUrl": "<personUrl>"
    },
    "name": "sync_conversation"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoSyncing period, not the depth of history: how many days new messages keep being added to the loaded history, from 1 to 90. Defaults to 30. The whole conversation is read regardless. Counted from the moment the action starts running; a reply does not extend it. Syncing the same person again keeps the history already collected and never shortens the period.
personUrlYesThe LinkedIn URL of the person whose message history you want to load (e.g., 'https://www.linkedin.com/in/john-doe')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

The description provides extraordinary transparency regarding the tool's asynchronous nature. It discloses that the tool merely queues a workflow, returns an immediate pending state, and requires long-polling via get_workflow_result, covering complex operational details not present in the annotations.

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 lengthy but every sentence is necessary, addressing distinct aspects of the workflow from core purpose to failure modes. The most crucial instructions (alternatives, workflow results) are front-loaded for immediate agent consumption.

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?

Given the tool's complexity (asynchronous queuing, workflow management, specific pending reasons), the description is maximally complete. It guides the agent through the entire lifecycle of the operation, from initial call to final result retrieval or error handling.

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?

Although the schema is complete, the description adds critical semantic context to the 'days' parameter. It clarifies that this parameter defines the sync period, not the depth of history, and explains the persistence of the sync period, adding meaning beyond what the schema provides.

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 states the tool's purpose: loading earlier message history. It also provides excellent differentiation by specifying that this tool is for historical synchronization, distinct from the function of get_inbox for checking new messages.

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?

Usage is guided by strict sequencing and exclusion: it explicitly tells the agent not to use this tool for new message checks and details the necessary subsequent steps (using get_inbox and get_workflow_result). It also includes a vital constraint against retrying while a workflow is running.

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.