HeyLead

Overview Schema Source Related Servers Discussions Admin

scheduler

Destructive

Control LinkedIn outreach automation: check status, toggle on/off, review logs and activity, run diagnostics, or move sending between cloud and local machine.

Instructions

Manage the autonomous scheduler — view status or toggle on/off.

Args:
    action: What to do:
        "status" — Show scheduler status, pending jobs, and recent activity
        "toggle" — Enable or disable the scheduler
        "observe" — Collect and classify signals, and check replies, while this
            machine sends nothing: no invitations, DMs, engagements, or
            enrolments. Local only — it does not stop 24/7 cloud scheduling,
            which must be disabled separately with
            scheduler(action='toggle', enabled=False, cloud=True)
        "always_on" — Enable/disable always-on mode (auto-re-enable + immediate email alerts)
        "logs" — Event log with job metrics and recent failures
        "activity" — Real action results from DB: what happened, what didn't, and why
        "diagnostics" — Full system diagnostics: rate limits, timers, blockers
        "report" — Configure periodic email campaign reports
        "backfill_cloud" — One-shot push of ALL local history (every campaign,
            any mode/status) to the hosted dashboard (backend mode only)
        "send_from" — Move all campaign outbound to the cloud or this machine.
            Pass host="cloud" (default for hosted accounts) or host="local".
            Local turns the cloud scheduler off so both never send.
    enabled: True to enable, False to disable (for 'toggle').
        For 'report': True to enable email reports, False to disable.
    cloud: If True, toggle the cloud scheduler for 24/7 operation (for 'toggle').
        Launching or resuming a campaign already switches it on for hosted
        accounts; pass cloud=True, enabled=False to stop the backend sending
        while leaving this machine's scheduler alone.
    hours: Lookback window in hours for 'logs' and 'activity' (default 24).
        For 'report': report interval in hours (1, 2, 4, 8, or 24).
        Omitted, 'report' leaves the stored interval unchanged.
    event_type: Filter events by type for 'logs'.
        For 'report': recipient email (empty = use login email).
    campaign_id: Filter by campaign for 'logs', 'activity', and 'diagnostics'.
    host: For 'send_from': "cloud" or "local".

Input Schema

TableJSON Schema

Name	Required	Default
`host`	No
`cloud`	No
`hours`	No
`action`	No	status
`enabled`	No
`event_type`	No
`campaign_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.375Sep 18, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Even though annotations mark destructiveHint=true and readOnlyHint=false, the description adds crucial behavioral context: it specifies which actions are destructive (toggle can disable), distinguishes local vs. cloud behavior, explains 'backfill_cloud' is backend-mode only, and clarifies 'send_from' ensures only one side sends. This goes well beyond the coarse annotation flags.

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 description is lengthy but well-structured: it opens with a one-line purpose, then uses a bulleted action list with inline parameter explanations. Given the tool's complexity (7 parameters, 10 actions, context-dependent semantics), the length is justified and every sentence earns its place, though it could be marginally tightened by moving parameter notes to a dedicated section.

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?

With an output schema present, return values needn't be described. The description covers every parameter, action, and interplay (e.g., cloud, enabled, host) plus edge cases like 'report' interval retention and 'send_from' ensuring mutual exclusivity. An agent can correctly invoke any action without external documentation.

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?

The schema provides zero descriptions for parameters (coverage 0%), so the description carries the full burden. It explains each parameter per action: e.g., 'hours' serves as lookback window for logs/activity but as report interval for 'report'; 'event_type' filters events but doubles as recipient email for 'report'. All parameters are fully and action-specifically clarified.

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 opens with a clear verb+resource statement: 'Manage the autonomous scheduler — view status or toggle on/off.' It then enumerates discrete sub-actions (status, toggle, observe, etc.) each with a specific purpose, making its scope unambiguous and distinct from sibling tools like 'show_status' or 'check_replies'.

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?

Every action is accompanied by explicit when-to-use guidance, including conditions and alternatives. For instance, it states that 'observe' is local-only and does not stop cloud scheduling, which must be disabled separately with a specific scheduler call. This leaves no ambiguity about selection among the available modes.

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