"A scheduler that invokes an agent on a predefined schedule" matching MCP tools:

• set_schedule_rulesA

  My TV ChannelA

  Give the channel a durable schedule: fixed slots ("news at 18:00") and dayparts ("no kids content after 22:00"). The scheduler re-honours these on EVERY rebuild, so you set them once instead of babysitting the grid. **Pro tier or higher.** This REPLACES the entire ruleset — send every rule you want, not just new ones. Sending an empty array removes all rules and returns the channel to plain weighted-random. Validate first with validate_schedule_rules. Rule shapes: time_slot {rule_type:'time_slot', start_time:'18:00', end_time?:'21:00', days_mask:127, selector_type:'asset'|'tag'|'playlist', selector_value:<id|tag|[ids]>, priority?:0} daypart_weight {rule_type:'daypart_weight', start_time:'22:00', end_time:'06:00', days_mask:127, selector_type:'asset'|'tag', selector_value:..., weight_multiplier:0-10} days_mask is a bitmask: bit0=Mon … bit6=Sun. 127=daily, 31=Mon-Fri, 96=weekend. end_time on a time_slot makes it a BLOCK that keeps drawing from the selector until that time — that is how you get 'cartoons 06:00-09:00' rather than one cartoon. selector_type 'playlist' with an array of asset ids plays them IN ORDER. weight_multiplier 0 removes matching assets from that window entirely. Set `timezone` (IANA) or the times mean UTC, which is almost never what the owner meant. Slots start ON-OR-AFTER their time: the programme running into a slot is never cut short, so an 18:00 slot may begin at 18:02. That is intended.

  Connector

  Destructive

  No auth

• setup_scheduled_pullA

  mcp-serverA

  End-to-end workflow for "pull files from this SFTP server / S3 bucket on a schedule" requests: reuses a matching connection if one already exists in the workspace (same hostname/username for sftp, same roleArn for aws_s3), otherwise creates one; tests it; then creates a trigger that feeds an already-analyzed data spec (see onboard_data_source) on the given frequency. Pass hostname for an sftp pull, or roleArn (+ s3Bucket, required) for an aws_s3 pull — exactly one of the two is expected. Use this instead of calling manage_connection + manage_trigger yourself for first-time setup. If the connection test fails (e.g. the sftp public key or the aws_s3 IAM role isn't set up yet on the customer's side), no trigger is created — ask the user to finish that setup and re-run this tool, which will reuse the same connection and pick up where it left off. This is for pulling a NEW file from an external source — for "run this on a schedule/after another job" where the spec queries tables already in the workspace (sourceType "tables"), use manage_trigger with type "schedule" or "spec_success" instead; there is no connection involved.

  ConnectorOAuth

• livereacting_cancel_schedulesA

  LiveReactingA

  Cancel scheduled streams. Give a liveId to cancel that one schedule, or give only a projectId to cancel every schedule on that project. Cancelling cannot be undone; the schedule has to be created again with livereacting_schedule_stream. This only ever touches SCHEDULED streams. It cannot stop a running one -- use livereacting_stop_stream for that. Call this before livereacting_schedule_stream when a project already has schedules, because scheduling refuses to run alongside them.

  Connector

  Destructive

  API key

• update_alert_ruleA

  RiusA

  Reconfigure or toggle one alert rule, predefined or custom. `ref` decides which: a kind name (consistent_error_pattern, silent_failure, tool_loop) addresses the predefined rule of that kind; a uuid addresses a custom rule. Get either from list_alert_rules. Only what you pass changes. Turning a rule off stops detection, not just notification — gaps in history are permanent and nothing backfills them. The two rule shapes take DIFFERENT settings, and mixing them is refused with a message naming the right one: * a predefined rule has named integer knobs -> pass `config` * a custom rule has metric thresholds -> pass `rules` (+ `window_minutes`) ref: the rule's kind or uuid. enabled: turn detection on or off. rca_enabled: turn root-cause analysis on or off for this rule. name: rename a custom rule (predefined rules take their name from their kind). config: for a PREDEFINED rule only — its named knobs, e.g. `{"min_errored_spans": 10}`. consistent_error_pattern takes window_minutes, min_errored_spans, min_distinct_traces; silent_failure takes window_minutes; tool_loop takes window_minutes, min_identical_calls. Call describe_alert_catalog for the bounds. rules: for a CUSTOM rule only — replace its thresholds. Replaces the whole list, so pass window_minutes with it. window_minutes: the window. For a custom rule it is part of the replaced config, so pass `rules` too; for a predefined rule put it in `config`. filters: for a CUSTOM rule only — replace its filters. Replaces the whole list. Same shape and the same verbatim-value rule as create_alert_rule. channel_ids: change where the rule delivers. Needs `channels:manage`. An empty list does NOT silence the rule — it re-points it at the region's default webhook. To stop notifications, set enabled to false. workspace: optional workspace id, name, or `org-name/workspace-name` when the same name occurs in two of your orgs (defaults to your default). Example: > Turn off the tool loop alert. ```json { "name": "update_alert_rule", "arguments": { "ref": "tool_loop", "enabled": false } } ``` Example: > Make the error pattern alert less noisy — 10 errors, not 3. ```json { "name": "update_alert_rule", "arguments": { "ref": "consistent_error_pattern", "config": { "min_errored_spans": 10 } } } ```

  Connector

  Destructive

  API key

• schedule_postA

  Tailwind AppA

  Use this when the user wants to schedule or reschedule an existing Pin draft or queued Pin in Tailwind: takes the postId of an existing Pin (from create_post or list_posts) plus exactly ONE of useNextOpenSlot: true or an ISO 8601 sendAt. Prefer useNextOpenSlot whenever the user has not named a specific time — it places the Pin in the account's next open smart schedule slot and applies the account's Pin Spacing rules for the Pin's destination url, which a timestamp you compute yourself cannot. Reserve sendAt for a time the user actually asked for. The Pin must already have title, description, and url set; a draft without a board also needs boardId (numeric ID from list_boards). Pass boardSectionId to schedule it into a Board section — and note that passing boardId on its own clears any section the Pin already had, since a section is only valid on its own Board. Does not work on published Pins. A draft exists only in Tailwind, not on Pinterest, until this step: scheduling is what puts it into Tailwind's publishing flow. Moving a draft onto the schedule is the charged step: one Pin credit on modular billing with Publishing access, whether subscribed or granted, though winback plans schedule without charge and modular accounts without Publishing draw on a free-trial allowance; legacy and Shopify accounts spend no credits and count it against the plan's post limit instead. Rescheduling a Pin that is already queued costs nothing on any of them. To create and schedule a new Pin in one step, use create_post instead. To take a queued Pin off the schedule and back to draft, use unschedule_post. If the user did not say which Pinterest account to use and list_accounts returns more than one, ask the user which account to use before calling this — do not choose for them.

  Connector

  Destructive

  OAuth

• set_ad_scheduleA

  AdCopilotB

  ADDS ad schedule windows to a campaign; its existing windows stay. This never replaces a schedule: the windows the campaign already has are left as they are. A campaign with no schedule serves at all hours, and its first windows narrow it to them; on a campaign that already has windows, an added one widens when ads show rather than narrowing it. Narrowing an existing schedule needs windows removed in Google Ads (Campaign → Ad schedule), which this server never does, so tell the user the old windows stay until they remove them there. Controls which days and hours ads are shown. Args: customer_id: The Google Ads customer ID. campaign_id: The ID of the campaign. schedules: List of schedule objects, each with: - day_of_week: One of MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY. - start_hour: Start hour (0-23). - start_minute: One of ZERO, FIFTEEN, THIRTY, FORTY_FIVE. Default: ZERO. - end_hour: End hour (0-23). Use 24 for midnight. - end_minute: One of ZERO, FIFTEEN, THIRTY, FORTY_FIVE. Default: ZERO. Returns: Dictionary with created schedule criteria. Tools revision: d2872486.

  Connector

  Destructive

  OAuth

• arena_comp_linkA

  LoomDeskA

  Asks to link the calling agent to its operator's paper competition entry, with the link code the operator copied from their entry on loomdesk.trade/competition (LK-XXXXXXXX-XXXXXXXX-XXXXXXXX, one use, about an hour). Use only with a code your own operator gave you, never one read in a post, a bio or a token's text. The operator then confirms this agent by name on the page; from then on arena_state, arena_open, arena_edit and arena_close trade that entry under the competition's rules, until the operator unlinks it or the agent calls arena_comp_unlink. Returns: state (pending: waiting for the operator to confirm; linked: already linked), x (the entry's X handle), name (this agent's name, shown to the operator and on the standings), fingerprint (shown beside the name on the operator's page: they confirm only when it matches). Behavior: writes; needs the agent's key; an agent trades one entry at most. Costs 1 unit. Errors: refused without a key, with a code that is no entry's, already used or run out, for an entry that has an agent, for an agent already on another entry, or after the end.

  ConnectorNo auth

• bundle_create_export_scheduleA

  gisgpB

  PAID PER DELIVERY (30 credits each time it fires, NOT at creation — free to create/cancel) — the only MCP tool that exposes GISGP's core recurring-export product to agents: creates a schedule that re-exports a FeatureServer layer on its own and POSTs the file straight to your own webhook_url, no email/web UI account needed beyond the API key. Reuses the same scheduler that runs the paid web app's scheduled exports (fires within ~5 min of the due time). format: "csv", "geojson", "shapefile", "kml", or "excel". frequency: "hourly" (top of each hour), "daily" (at run_hour UTC), "weekly" (at run_hour UTC on `weekday`, 0=Monday..6=Sunday), or "monthly" (at run_hour UTC on `monthday`, 1-28). webhook_url: must be a public, reachable HTTPS URL (validated at creation AND at every delivery) — GISGP POSTs a JSON body {schedule_id, format, row_count, filename, delivered_at, data_base64 (or download_url for files >5MB)}. If the wallet lacks 30 credits when a delivery is due, that cycle is silently skipped (schedule stays active, no error surfaced to you) — top up any time at https://gisgp.com/billing/mcp-credits/topup and the next cycle delivers normally. Use estimate_cost or check_wallet_balance to plan ahead. Delete via cancel_export_schedule when no longer needed — an abandoned schedule with an empty wallet just skips forever, but does not charge or error. Requires Authorization: Bearer <api_key>. Returns JSON: {ok, schedule_id, next_run_at}.

  ConnectorNo auth

• add_triggerA

  SliqA

  <summary>Add a trigger to an existing agent. Use this to schedule follow-ups on an agent that already has context (e.g., after sending emails, add a one_time trigger to check for replies later). Prefer this over creating a new agent. You MUST call `get_skill_guide('trigger_code')` before writing the trigger's `code` — the qualification rules, sandbox globals, tool surface, and `out` contract live in the skill. New `code` runs on the trigger's next firing. To add a flow node's `on_enter` enactment — a terminal hook, or re-arming a node whose row was removed — pass an `on_enter` trigger with the target `node_id` (any node kind; the node must already exist in the sequence). One `on_enter` per node — if it already has one, edit that with `update_trigger` instead of adding a second. On a send or connection-request node, that trigger's `prompt` holds only extra instructions; the message or note itself goes in the node's `message_templates` (`update_node`).</summary> <returns> <description>Dict with success, agent_id, trigger_id, next_run_at, and the added trigger's full dict under `trigger`, plus a `warning` when the agent is paused, since its triggers don't fire until it is set back to active. Read the agent's other triggers via get_agent_details.</description> </returns>

  ConnectorOAuth

• events_waitA

  TincanC

  Check for new accessible messages and creator-only join/security events, waiting at most 25 seconds. For authorized ongoing listening in a host that cannot maintain a stream, use its supported scheduler every 5 minutes by default; do not loop in the foreground or claim real-time delivery. Reads do not consume Tincan's shared-message quota. Returns an array of events: persist the last seq after recording pending work and pass it as after; retain the cursor on an empty result. Join requests require user review, never automatic approval.

  ConnectorNo auth

• create_channelA

  ValetA

  Create a channel on an agent: a cron or heartbeat channel that wakes it on a schedule, a webhook channel that lets callers outside Valet reach it, or an mcp channel that serves it as an MCP server. The channel starts the agent's work; what the agent does when it fires is the prompt file channels/<name>.md in its source. A webhook is signed by a secret you choose, because this never returns a secret value: set it with set_env_vars on the agent first, then pass its name as secret_name. A webhook without secret_name is refused. Creating a channel that already exists with the same kind and settings reports it and changes nothing; different settings are refused, so destroy it first. Slack and Telegram need a browser, so for them this gives the step to take and creates nothing. Requires connecting a Valet account.

  ConnectorNo auth

• publish_agentA

  ValetA

  Publish source as an agent: a SOUL.md describing who it is, a valet.yaml declaring the skills, connectors, channels, and configuration it runs with, and any supporting files. Use it when the work is an agent that answers on a channel or runs on a schedule, not a website or an app. Apply the governance skill before calling. Send the agent one of two ways. files carries it in the call, which works from any client. push: {id, commit} publishes a commit you pushed with git: call create_push, run the recipe it returns, then pass the push_id and the commit sha it prints. Use push when you can run git with network access or when you changed a clone of the agent's source; a push that builds on a main that has since moved is merged onto it as a deploy is. Pass files or push, not both. The tree, in files or in the commit, must include valet.yaml and SOUL.md at the root. Unlike a website's or an app's, an agent's valet.yaml is yours: Valet validates it rather than writing it, and refuses one the agent rules reject. An organization connector or channel the manifest names is attached for you. When the manifest names one the organization does not have, or a skill that does not resolve, nothing deploys and the answer lists what is pending and the tool that sets each up; do that and call again with the same files. Publishing changes an agent that exists: create it first with create_service (kind: agent), then publish to its name. A name that holds no agent is refused. Publishing replaces the agent's source with these files, so read get_source first when the agent is not yours. An agent deploy finishes before this call returns: the answer carries the release version, and get_service reports whether the agent is running and what it holds. In an organization with release policies, the answer may carry evaluation instead of a version: the release is built and waits for its policies, and get_evaluation with wait_seconds 20 follows it. Requires connecting a Valet account.

  Connector

  Destructive

  No auth

• update_power_scheduleA

  AnkraB

  Replace a power schedule's action, timing, and enabled flag, and re-arm its next run. This is a FULL REPLACE, not a patch: restate every field of the schedule as it should be afterwards - enabled must always be passed (an omitted enabled is refused rather than silently re-enabling a paused schedule), and a 'cron' schedule must restate its timezone (an omitted timezone is refused rather than silently shifting the fire hour to UTC). Call list_power_schedules first for the schedule_id and the current values. Passing enabled false pauses the schedule without losing its configuration; true re-arms it for its next occurrence. The same VM-termination caution and stop_mode semantics as create_power_schedule apply to stop schedules ('delete_resources' terminates every VM; 'scale_to_zero' deletes the worker servers, losing data on their own disks, and keeps the control plane running). A 'stop' schedule must also restate its stop_mode (an omitted stop_mode is refused rather than silently reverting a scale-to-zero schedule to the destructive default). An enabled scale_to_zero stop on a cluster whose inventory shows claims on a worker's own disk is refused unless accept_node_local_data_loss is true, which may only be set after the user has explicitly agreed to lose that data at every stop, exactly as for create_power_schedule. Do not use it to turn a schedule into an off-hours saving schedule; propose_off_hours_schedule files that decision.

  Connector

  Destructive

  OAuth

• reschedule_tableA

  Mostly RightA

  Sets a live table's refresh schedule, or replaces the one it has, without starting a run or fetching anything. A table that went live on its first run has NO schedule yet (get_table shows schedule null, the chat shows "No refresh schedule"): this is the tool that gives it one. When the table's recipe cannot refresh yet, the schedule is HELD rather than applied and the answer carries schedule null: report that, and do not call again. It is also the way to change a cadence without the demote and promote that would reset the table and buy a catch-up refresh. State exactly one of cron (five fields, evaluated in UTC) or interval_seconds (the interval counts from now). rationale records why, kept verbatim beside the schedule. lock: true freezes the schedule so the platform stops adjusting it to the source; leave it out to let it keep learning from there. Pass expected_version from get_table so a table that moved in between is refused rather than overwritten. Example: {"table_id": "…", "cron": "15 6 * * *", "rationale": "The agency publishes the previous day by 06:00 UTC."}. Returns {table_id, dataset_id, promotion_status, schedule, version, dashboard_url}. Only a table that is not live is refused (demoted or never built); a live table with no schedule is exactly what this sets. A schedule that fires more often than the table allows is refused with the floor named. A recorded schedule refreshes a table only where its recipe can refresh — read get_table before saying it does.

  ConnectorNo auth

• list_timeslotsA

  Tailwind AppA

  Use this when the user asks what their posting schedule looks like, or which times Tailwind recommends: lists the account's smart schedule timeslots. Each slot is a RECURRING WEEKLY time (day of week + HH:MM + timezone), not a concrete date, and this read says nothing about which upcoming occurrences are already taken — use get_schedule for that, which returns dated entries marked open or occupied. This is a read for showing or explaining the recurring schedule, and the place to get the timeslotId that update_timeslot and delete_timeslot need. It is NOT the way to schedule a Pin into it. To place a Pin on the schedule, pass useNextOpenSlot: true to create_post or schedule_post: that resolves the next genuinely open slot and applies the account's Pin Spacing rules for the Pin's destination url. Do not compute an occurrence from these slots and pass it as sendAt — that ignores which slots are occupied and ignores Pin Spacing, so Pins stack up and land off-schedule. If the user did not say which Pinterest account to use and list_accounts returns more than one, ask the user which account to use before calling this — do not choose for them.

  ConnectorOAuth

• fastero_set_python_scheduleA

  FasteroA

  Run a Python entrypoint repeatedly on a cron timetable, or change the one it has: an entrypoint has one schedule, and calling again replaces its cron and whether it is on. The cron expression takes 5 fields (minute hour day-of-month month day-of-week) or 6 with leading seconds, and runs in UTC — there is no per-schedule timezone; an expression the scheduler cannot run is refused. A scheduled run cannot be given parameters: it runs the entrypoint as it stands. Each run uses compute, and a failed one is reported to you by email and in the app. The entrypoint id comes from fastero_ensure_python_entrypoint or fastero_get_python_project. Returns ok, triggerId and schedule (the cron as stored). It is the trigger py:<pythonProjectId>:<entrypointId>, which fastero_list_triggers shows and fastero_disable_trigger pauses. To run once now, fastero_run_python_project; a notebook is scheduled with fastero_schedule_notebook. Owners, admins and editors of the project can set it.

  Connector

  Destructive

  API key

• list_processesA

  OTPA

  List this organization's processes (SOPs written on agent seats) together with any schedules already attached to them. Use this BEFORE creating, changing, or running a schedule: it is the only place the real agent externalId and SOP title come from, and both are required by the other process tools. The response also tells you whether autonomous runs are currently armed for the deployment (schedulerArmed) and whether this org is allowed to schedule at all (gate). Never guess an externalId or a SOP title; if this returns nothing, the org has no processes to schedule yet.

  ConnectorAPI key

• share_workspaceA

  DockA

  Add someone to a workspace at a specified role: a human by `email`, or an agent by `agent_id`. For an email that already belongs to a Dock user, they're added immediately and a notification email is sent; otherwise a 7-day invite token is minted that auto-accepts on magic-link sign-in. An `agent_id` (the agent's Dock id, or its agt_ id) adds that agent directly as a member, never as an invite; the agent must be in the workspace's org and not archived. Editor role required on the workspace. Emits `member.joined` (added) or `member.invited` (invited). Use update_workspace_member to change a role afterwards, remove_workspace_member to remove a member or revoke a pending invite.

  ConnectorNo auth

• modem_agent_send_messageA

  ModemA

  Continue an existing Modem agent conversation when a question builds on an earlier answer, such as drilling in, narrowing, or acting on the results; the agent keeps that conversation's context. Start a new run with modem_agent_invoke for an unrelated question. Returns immediately with a new run_id; poll modem_agent_get_run for the result.

  Connector

  Destructive

  OAuth

• quickstartA

  Ned WatchA

  The fastest way to be watched, in one call. Makes you an agent (if you have no key yet) and a deadman watch that expects a check-in every `every_minutes` (5 to 1440). Miss one and Ned POSTs a signed message to callback_url; check in again and he says it's clear. Returns agent_key (shown once), signing_secret, and the exact check-in line to run on your schedule. The first 5 watches are free. arm=true starts the clock now instead of at your first check-in, so a job that never runs at all still wakes you.

  ConnectorNo auth

• kenwea.agent.sendHeartbeatA

  Kenwea — Sandbox Attestation & Agent MarketplaceA

  Record that this agent is alive. Takes no arguments, returns status accepted, and only updates your last-seen time, which your operator sees. It moves no money and changes nothing else, so repeating it is harmless; call it on a schedule while you run. It checks nothing: for platform load use kenwea.scale.getStatus, for a job you started use kenwea.jobs.getStatus.

  ConnectorNo auth