Skip to main content
Glama

LinkedIn MCP Server (Salesbot)

by cz.salesbot
OverviewDiscussionsAdmin

send_email

Queue a personalised e-mail for one person, either through a connected Smartlead or Instantly campaign (provider + provider_campaign_id from list_email_campaigns) or from the user's own mailbox (provider 'mailbox', provider_campaign_id = mailbox_id from list_email_integrations; it is then sent by Salesbot inside the user's sending hours, spaced out and capped per day — status queued → sent). Pass crm_lead_id or contact_id, subject and body (placeholders like {{first_name}}, {{company}}, {{oslovení}} are filled per person). If the person has no address, pass email — it is saved to the contact. When approval is required (see list_email_integrations) the e-mail waits in Salesbot for the user (status pending_approval) — tell the user, never claim it was sent. Otherwise it is pushed to the provider immediately (status queued); the provider then sends it on its own schedule. Refuses blacklisted domains and duplicates in the same provider campaign. Statuses: pending_approval (waits for the user in Salesbot → CRM → E-maily), approved (approved, not yet in the provider — usually a temporary provider error; retry by approving again), queued (in the provider campaign, or waiting for its slot in the user's own mailbox), sending, sent, replied, bounced, unsubscribed, paused, completed, failed (see error), rejected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesPlain-text e-mail body.
emailNoRecipient address; required when the person has none saved.
subjectNo
providerYes
contact_idNo
crm_lead_idNo
followup_bodyNoOptional follow-up used by {{email_1follow_up_body}}.
provider_campaign_idYesProvider campaign id, or mailbox_id for provider 'mailbox'.
provider_campaign_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / provider / enum
      Previous value: -[
-  "smartlead",
-  "instantly"
-]New value: +[
+  "smartlead",
+  "instantly",
+  "mailbox"
+]
    • addedInput schema / properties / provider_campaign_id / description
      Added value: +"Provider campaign id, or mailbox_id for provider 'mailbox'."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the annotations: discloses approval-gated pending_approval state, instructs the agent to never claim an unapproved email was sent, reveals mailbox scheduling and daily caps, and documents blacklist/duplicate refusal. The long status list adds genuinely useful runtime behavior context.

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 core action and scope, then flows logically through routing, approval, restrictions, and statuses. It is long, but the status enumeration and approval caution each carry operational value rather than padding.

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 9-parameter tool with no output schema and sparse annotations, the description covers targeting, required parameters, provider routing, approval workflow, blacklist/duplicate safeguards, scheduling, and status meanings. No critical decision an agent needs to call this correctly is missing.

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 only 44%, and the description compensates well: it explains the provider enum semantics, provider_campaign_id vs mailbox_id mapping, the contact_id vs crm_lead_id alternatives, and the email fallback. followup_body is only tied to a placeholder and provider_campaign_name is not explained, so a small gap remains.

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 action and resource: 'Queue a personalised e-mail for one person', and names the three delivery channels (Smartlead, Instantly, mailbox). This clearly distinguishes it from siblings like send_linkedin_message or approve_message even 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?

Provides clear routing guidance: references list_email_campaigns for campaign IDs and list_email_integrations for mailbox_id, explains when to pass email versus relying on a saved address, and points to list_email_integrations for approval requirements. It lacks explicit exclusions ('use X instead for LinkedIn'), but the provider/campaign context is sufficient.

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

All LinkedIn MCP Server (Salesbot) 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