Skip to main content
Glama

Sliq

by com.getsliq
OverviewDiscussionsAdmin

Fetch Linkedin Messages With Person

fetch_linkedin_messages_with_person
Read-only

Query the local store with search_linkedin_message_history first. Reach for this tool only when that misses, when you need messages older than the roughly two-week local backfill window, or when you must be certain whether a conversation exists — this reads LinkedIn's own synced history, so an empty result here means no such conversation, not merely "outside the local window". Fetched messages are written back to the local store, so a later search_linkedin_message_history sees them too.

This is not a name-lookup tool: pass the person's LinkedIn provider_id, sourced from a prospect row, search_linkedin_connections, or a prior local message — never guessed from a name. On success, a dict with success=True, chat_id (pass to setup_linkedin_sequence with action_type='message' to reply), count, truncated (True when older messages exist beyond the fetch cap), messages — newest first, each with direction ('sent'/'received', or 'unknown' when LinkedIn omits the sender flag), message_datetime (ISO), and content (truncated to 1000 chars) — and connection_request_note: the note on your accepted connection request, which LinkedIn replays into the chat when they accept, as message_datetime + content (null when there's none). It's the invite, not a message you sent them, so it's kept out of messages and count. On failure, success=False and error; an error that mentions reconnecting means the user must reconnect LinkedIn in Settings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_teammateNoRead a consented teammate's LinkedIn history instead of your own — pass their email. Gated on that teammate's conversation-sharing setting; a teammate who hasn't shared is rejected. Reads via the teammate's own LinkedIn connection and caches the result to their local store. Omit for your own.
provider_idYesThe other person's LinkedIn provider_id (the `sender_provider_id` / `recipient_provider_id` on message and connection rows).

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?

Annotations only declare readOnlyHint, but the description adds substantial behavior: results are written back to the local store so later searches see them, an empty result is authoritative rather than a cache miss, the fetch is capped (truncated flag), and errors mentioning reconnection require the user to reconnect in Settings. These are traits the annotations do not convey.

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?

Front-loaded summary of what it does and when to use it, followed by the returns/error contract. No filler sentences; every clause carries operational information (backfill window, write-back, provider_id sourcing).

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?

Even without an output schema, the <returns> block documents success/failure shape, chat_id handoff to setup_linkedin_sequence, message fields, truncation, and the connection_request_note edge case, including why it is excluded from messages/count. Nothing an agent needs to call or interpret the result is missing.

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?

Schema coverage is 100% and already documents as_teammate thoroughly, but the description still adds real value: it identifies provider_id as a LinkedIn provider_id with named sources (prospect row, search_linkedin_connections, prior message) and explicitly forbids guessing from a name. That closes a common misuse path the schema alone does not.

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 summary states a specific verb and resource ('fetch the user's full LinkedIn message history with one person') plus the source ('live from LinkedIn via Unipile'). It explicitly distinguishes itself from the sibling local-store tool search_linkedin_message_history, so an agent can route without opening either schema.

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?

It gives an explicit ordering rule ('Query the local store with search_linkedin_message_history first. Reach for this tool only when...'), names the three triggering conditions (cache miss, older than the ~2-week backfill, need certainty about existence), and states what an empty result means. This is textbook when/when-not guidance.

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

All Sliq toolsInspect
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