Skip to main content
Glama

PoliteReach

by com.politereach
OverviewDiscussionsAdmin

Booking Follow-Through Settings

li_set_booking_settings
Destructive

Set one account's booking follow-through settings — the same ones as the dashboard's account page. Writes our database only; fields you omit keep their values, numbers are clamped to their bounds (the reply lists clamped), and the reply returns the account's full booking block. Current values are in li_list_accounts. Name the account when you hold several; it is never guessed.

  • bookingUrls: the booking links this account sends (cal.com / Calendly …). ANY outgoing message containing one — a sequence step, li_send_reply, or a message typed by hand in LinkedIn that the inbox sweep stores — marks the booking link as sent. Matched ignoring case, scheme, www and a trailing slash; a deeper path of a listed link counts too.

  • firstNudgeHours, closeAfterDays, maxNudges, cancelRecheckHours: when li_booking_due lists someone and whether its next action is a nudge or a close.

  • prefillName (default true): every outgoing message gets the recipient's cleaned name added to the booking link as a query parameter (cal.com name; Calendly name + first_name + last_name), so the booking comes back under the name li_match_contacts expects. The link stays the real link — no redirect, no shortener; links that are not this account's booking links are never touched; a link already carrying the name is left alone. Write the plain link in a message; PoliteReach adds the name.

  • bookingTool (default auto) and nameParam (default none): only for a self-hosted or unknown booking page, which is left unchanged unless nameParam is set. The defaults work for cal.com and Calendly.

Input Schema

NameRequiredDescriptionDefault
maxNudgesNoNudges before a close (default 1, 0-3)
nameParamNoOverride the query parameter the name goes in; '' clears it.
sessionIdNoAccount id from li_list_accounts. Needed (or sessionLabel) when you have more than one account; never guessed.
bookingToolNoWhich booking tool the links are; auto detects it from the host.
bookingUrlsNoREPLACES the list. [] clears it.
prefillNameNoAdd the recipient's name to the booking link (default true).
sessionLabelNoAccount by label, LinkedIn name, profile slug or member id (li_list_accounts). Needed (or sessionId) when you have more than one account; never guessed.
closeAfterDaysNoDays after a nudge before the next action becomes a close (default 3, 1-30)
firstNudgeHoursNoHours after the booking link before the first check (default 48, 1-336)
cancelRecheckHoursNoHours after a cancelled booking before it is due again (default 24, 1-336)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / cancelRecheckHours / description
      Added value: +"Hours after a cancelled booking before it is due again (default 24, 1-336)"
    • addedInput schema / properties / closeAfterDays / description
      Added value: +"Days after a nudge before the next action becomes a close (default 3, 1-30)"
    • addedInput schema / properties / firstNudgeHours / description
      Added value: +"Hours after the booking link before the first check (default 48, 1-336)"
    • addedInput schema / properties / maxNudges / description
      Added value: +"Nudges before a close (default 1, 0-3)"
    • addedInput schema / properties / sessionId / description
      Added value: +"Account id from li_list_accounts. Needed (or sessionLabel) when you have more than one account; never guessed."
    • addedInput schema / properties / sessionLabel / description
      Added value: +"Account by label, LinkedIn name, profile slug or member id (li_list_accounts). Needed (or sessionId) when you have more than one account; never guessed."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: writes only the database, omitted fields keep their values, numbers are clamped with the reply listing 'clamped', bookingUrls replaces the list ([] clears it), and prefillName/bookingTool/nameParam have detailed conditional effects. This fully addresses the destructiveHint=true profile.

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?

Long but well-structured: the purpose is front-loaded, followed by key caveats and a bulleted parameter breakdown. Every major sentence earns its place, though the overall length is on the verbose side even for a 10-parameter tool.

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 10 optional parameters, no output schema, and destructive annotations, the description is complete: it covers account identification, default-omission behavior, clamping, replacement semantics, and return-block content. An agent has what it needs to invoke the tool correctly.

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 schema coverage is 100%, the description adds deep meaning beyond the schema, such as booking-link matching rules (case, scheme, www, trailing slash, deeper paths), what firstNudgeHours/etc. control, prefillName's exact query-parameter behavior, and the self-hosted-only condition for bookingTool/nameParam.

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 verb and resource: 'Set one account's booking follow-through settings — the same ones as the dashboard's account page.' It clearly distinguishes this settings-writer from read-oriented siblings like li_list_accounts and li_booking_due.

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 context: current values are in li_list_accounts, and the account must be named when several exist ('it is never guessed'). It also relates parameters to li_booking_due and li_match_contacts, but gives no explicit when-not conditions.

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

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