Skip to main content
Glama

Create Sending Strategy

li_create_strategy

Create a reusable sequence template: which post-acceptance steps to send, the delay in hours before each, and connectionWaitHours (how long to wait after the invite is accepted before the first message). A sequence may hold AT MOST 4 messages, chosen from the five kinds (first, followup_1..3, closer) — a fifth message is refused. Check li_list_strategies first: an existing template may fit, and names are unique per team. Dry-run unless confirmCreate=true; the preview returns the validated steps and any errors, the confirmed call the new strategy with its id for li_create_campaign / li_ingest_prospects. Steps are snapshotted onto each prospect at import, so fixing copy already queued is li_bulk_edit_steps or li_edit_step, not a new strategy. It belongs to YOUR team (the reply's owner says whose). An operator credential with no team must name the account whose team owns it (sessionLabel) or pass shared:true; it is never published to every team by default.

Input Schema

NameRequiredDescriptionDefault
nameYesTemplate name, unique within your team (check li_list_strategies first)
stepsYesOrdered steps, at most 4; must start with {kind:"first", delayHours:0}
sharedNoOperator only: true publishes it as a shared template every team sees. Never the default.
sessionIdNoOperator only: the account whose TEAM owns it. Members' creates are their team's.
descriptionNoOptional note on when to use this template
sessionLabelNoOperator only: the account whose TEAM owns it. Members' creates are their team's.
confirmCreateYesMust be true to write the strategy to the database
connectionWaitHoursNoHours to wait after a connection is ACCEPTED before sending the first message (default 24)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / sessionId
      Added value: +{
      +  "description": "Operator only: the account whose TEAM owns it. Members' creates are their team's.",
      +  "type": "string"
      +}
    • addedInput schema / properties / sessionLabel
      Added value: +{
      +  "description": "Operator only: the account whose TEAM owns it. Members' creates are their team's.",
      +  "type": "string"
      +}
    • addedInput schema / properties / shared
      Added value: +{
      +  "description": "Operator only: true publishes it as a shared template every team sees. Never the default.",
      +  "type": "boolean"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / description / description
      Added value: +"Optional note on when to use this template"
    • addedInput schema / properties / name / description
      Added value: +"Template name, unique within your team (check li_list_strategies first)"
    • addedInput schema / properties / steps / items / properties / kind / description
      Added value: +"Which message this step is; each kind at most once"
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare the write/non-destructive/non-idempotent/open-world profile, and the description adds substantial context beyond that: a hard cap of 4 messages with a fifth refused, dry-run preview semantics vs confirmed write, snapshotting onto prospects at import, team ownership rules, and the operator-only sessionLabel/shared behavior with the guarantee it is never published by default.

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?

A single dense block that is front-loaded with the core action, then constraints, then routing, then ownership. Every sentence carries distinct information, though the run-on length makes it slightly harder to scan than an ideal definition.

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 an 8-parameter creation tool with no output schema, the description covers return shapes (preview returns validated steps and errors; the confirmed call returns the new strategy with its `id`), downstream consumers, ownership defaults, and failure modes — nothing an agent needs to call it 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 100%, so the baseline is 3, but the description adds genuine meaning: the at-most-4 message cap, the requirement to start with 'first', connectionWaitHours semantics (wait after acceptance before the first message), and what confirmCreate actually gates (dry-run vs real write). It stops short of documenting every operator-only field, so 4 rather than 5.

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 opening sentence gives a precise verb+resource ('Create a reusable sequence template') and immediately enumerates its constituents: steps, delays, and connectionWaitHours. It distinguishes itself from li_create_campaign, li_edit_step, and li_bulk_edit_steps by naming each and the condition that routes to it.

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?

Explicit when-to-use: check li_list_strategies first for an existing fit, dry-run unless confirmCreate=true, and fix already-queued copy via li_bulk_edit_steps/li_edit_step rather than creating a new strategy. Both alternatives and exclusions are named, leaving nothing to inference.

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.

Resources