Skip to main content
Glama
Sign In

LinkedNav

by io.github.linglistack
OverviewDiscussionsAdmin

Schedule sends

schedule_sends

PLAN LinkedIn sends at chosen times: posts, connection invitations, messages / follow-ups, InMails and comments, each with its own date and time, approved once as a whole and then sent by themselves at their times. Use it when the user asks to schedule specific sends ("post these on Mondays at 9", "follow up with Jane Tuesday 10am", "a 30-day post calendar"). Write every text FIRST and pass the final words: posts with draft_post (one draft per call; for a calendar, ask the user for the facts and stories the shapes need before drafting many — never pad with thin filler), outreach sequences with generate_message_templates, a one-off message or follow-up in the user's voice. Every item is checked against the same rules the immediate tool applies (lengths, profile / post links, the account's daily allowance per day, a person a campaign already invited or InMailed) — a list with a problem saves NOTHING and names each item to fix. Times are the user's local time ("YYYY-MM-DDTHH:MM"); the answer states their time zone and today's date. Limits: at most 90 days ahead, 60 sends per plan, and 25 invitations / messages / InMails per plan — more people than that is a campaign's work (it paces, follows up and stops on a reply by itself): suggest a campaign instead. SAVES A DRAFT ONLY: nothing is scheduled or sent until approve_scheduled_plan. Show the user the whole list the answer returns (day and time, what, to whom, the words) and ask for their yes. Pass planId to add sends to a plan that is not approved yet.

Input Schema

NameRequiredDescriptionDefault
itemsYesThe sends, each with kind, at and its fields.
planIdNoAdd these sends to this draft plan instead of starting a new one.
planNameNoA short name for the plan, e.g. "30-day post calendar" or "Follow-ups this week".
timezoneNoIANA time zone the times are in (e.g. "America/New_York"). Omit to use the user's own.
connectionIdNoWhich of the user's LinkedIn accounts sends them (from get_linkedin_accounts). Omit for their first live account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the draft-only state, the need for later approval, validation behavior that saves nothing if any item has a problem, naming of items to fix, plan limits, and the fact that nothing is scheduled or sent until approve_scheduled_plan. This is rich behavioral context and is consistent with readOnlyHint=false and destructiveHint=false.

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?

The definition is front-loaded with purpose and usage, then moves through drafting prerequisites, validation, limits, and approval behavior. It is appropriately detailed for a complex scheduling tool, though some sentences are long and packed with parenthetical workflow guidance.

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 complex nested item schema, no output schema, and sparse annotations, the description covers what an agent needs: what the tool does, how to prepare text, local-time format, limits, validation failure behavior, draft/approval state, and what the answer should show the user. The nested field details are fully covered by the schema.

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 schema already carries most field-level meaning. The description still adds operational parameter constraints not present in the schema, notably the 90-day advance limit and the 25 invitations/messages/InMails per plan cap, and clarifies that planId only adds to a plan that is not approved yet.

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 uses a specific verb and resource: scheduling LinkedIn sends at chosen times, covering posts, invitations, messages, InMails, and comments. It clearly distinguishes this tool from immediate-send siblings by stating 'SAVES A DRAFT ONLY' and from campaigns by saying larger lists should use a campaign.

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 explicit trigger examples such as scheduling posts on Mondays at 9 or following up with Jane Tuesday 10am. It also names prerequisites and alternatives: write text first via draft_post or generate_message_templates, use approve_scheduled_plan before anything sends, and suggest a campaign when the list exceeds 25 invitations/messages/InMails.

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

All LinkedNav 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