Skip to main content
Glama

mcphost

by dev.mcphost
OverviewDiscussionsAdmin

host.trigger.set

Run a published tool on a cron schedule (5-field: minute hour day-of-month month day-of-week, UTC), give it a public webhook URL (kind="event"): a signed POST to that URL runs the tool with the event as its argument, fire it whenever this tenant receives a message (kind="message"): the tool runs with the message envelope as its argument, or give it an inbound-inbox URL (kind="webhook"): a verified POST lands as a row in state table inbox_ and fires the tool with that row as its argument -- the response carries {url, secret} once (host.trigger.get afterwards never returns the secret again). Each firing/delivery is a run visible in host.runs.list(trigger="schedule"|"event"|"message"|"webhook"). Refuses schedules_max (trigger_quota_exceeded, shared by schedule and webhook triggers), event_triggers_max (shared by event and message triggers) or a too-short schedule interval (trigger_interval_too_short); an invalid expression or verify config fails trigger_invalid naming the field.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tzNokind="schedule" P1: only "UTC" (or omitted) works today.
argsNoArguments passed to the tool on each firing/delivery (kind="schedule"/"event" only -- a message trigger's whole argument is the message envelope and a webhook trigger's whole argument is the stored inbox row).
fromNokind="message": only fire for messages from this address (@handle or t_... namespace); omit to fire for any sender.
kindNo"schedule" (default), "event", "message" or "webhook".
nameNokind="webhook": letters/digits/underscore -- becomes the inbox_<name> state table each accepted delivery is stored in.
toolYesThe published tool this trigger runs.
verifyNokind="event": {scheme: "hmac-sha256"|"hmac-sha1"|"token"|"none", header, secret (a host.secret_set name), prefix?, timestamp_header?, tolerance_s?, allow_unverified? (required true for scheme "none")}. kind="webhook": a plain string, one of "hmac" (default; checks X-Mcphost-Signature: sha256=<hex>), "none", or "stripe" (checks Stripe-Signature the way Stripe itself signs, using the same generated secret).
scheduleNokind="schedule": 5-field cron expression (minute hour day-of-month month day-of-week), UTC. Supports *, lists, ranges and steps.
channel_idNokind="message": scope this trigger to one group channel's posts (host.channel.open's channel_id) instead of ordinary host.msg.send/reply deliveries.
tenant_keyNoThe key `signup` returned. Required only when this connection carries no Authorization: Bearer header -- when both are present, the header wins.
dedupe_headerNokind="event": a header (e.g. X-GitHub-Delivery) whose repeated value within 24h answers 202 with the original run id instead of running again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / args / description
      Previous value: -"Arguments passed to the tool on each firing/delivery (kind=\"schedule\"/\"event\" only -- a message trigger's whole argument is the message envelope)."New value: +"Arguments passed to the tool on each firing/delivery (kind=\"schedule\"/\"event\" only -- a message trigger's whole argument is the message envelope and a webhook trigger's whole argument is the stored inbox row)."
    • changedInput schema / properties / kind / description
      Previous value: -"\"schedule\" (default), \"event\" or \"message\"."New value: +"\"schedule\" (default), \"event\", \"message\" or \"webhook\"."
    • addedInput schema / properties / name
      Added value: +{
+  "description": "kind=\"webhook\": letters/digits/underscore -- becomes the inbox_<name> state table each accepted delivery is stored in.",
+  "type": "string"
+}
    • changedInput schema / properties / verify / description
      Previous value: -"kind=\"event\": {scheme: \"hmac-sha256\"|\"hmac-sha1\"|\"token\"|\"none\", header, secret (a host.secret_set name), prefix?, timestamp_header?, tolerance_s?, allow_unverified? (required true for scheme \"none\")}."New value: +"kind=\"event\": {scheme: \"hmac-sha256\"|\"hmac-sha1\"|\"token\"|\"none\", header, secret (a host.secret_set name), prefix?, timestamp_header?, tolerance_s?, allow_unverified? (required true for scheme \"none\")}. kind=\"webhook\": a plain string, one of \"hmac\" (default; checks X-Mcphost-Signature: sha256=<hex>), \"none\", or \"stripe\" (checks Stripe-Signature the way Stripe itself signs, using the same generated secret)."
    • removedInput schema / properties / verify / type
      Removed value: -"object"
  2. Changed1 schema field changed
    • addedInput schema / properties / channel_id
      Added value: +{
+  "description": "kind=\"message\": scope this trigger to one group channel's posts (host.channel.open's channel_id) instead of ordinary host.msg.send/reply deliveries.",
+  "type": "string"
+}
  3. Changed3 schema fields changed
    • changedInput schema / properties / args / description
      Previous value: -"Arguments passed to the tool on each firing/delivery."New value: +"Arguments passed to the tool on each firing/delivery (kind=\"schedule\"/\"event\" only -- a message trigger's whole argument is the message envelope)."
    • addedInput schema / properties / from
      Added value: +{
+  "description": "kind=\"message\": only fire for messages from this address (@handle or t_... namespace); omit to fire for any sender.",
+  "type": "string"
+}
    • changedInput schema / properties / kind / description
      Previous value: -"\"schedule\" (default) or \"event\"."New value: +"\"schedule\" (default), \"event\" or \"message\"."
  4. Changed8 schema fields changed
    • changedInput schema / properties / args / description
      Previous value: -"Arguments passed to the tool on each firing."New value: +"Arguments passed to the tool on each firing/delivery."
    • addedInput schema / properties / dedupe_header
      Added value: +{
+  "description": "kind=\"event\": a header (e.g. X-GitHub-Delivery) whose repeated value within 24h answers 202 with the original run id instead of running again.",
+  "type": "string"
+}
    • changedInput schema / properties / kind / description
      Previous value: -"Trigger kind; only \"schedule\" works today."New value: +"\"schedule\" (default) or \"event\"."
    • changedInput schema / properties / schedule / description
      Previous value: -"5-field cron expression (minute hour day-of-month month day-of-week), UTC. Supports *, lists, ranges and steps."New value: +"kind=\"schedule\": 5-field cron expression (minute hour day-of-month month day-of-week), UTC. Supports *, lists, ranges and steps."
    • changedInput schema / properties / tool / description
      Previous value: -"The published tool this schedule runs."New value: +"The published tool this trigger runs."
    • changedInput schema / properties / tz / description
      Previous value: -"P1: only \"UTC\" (or omitted) works today."New value: +"kind=\"schedule\" P1: only \"UTC\" (or omitted) works today."
    • addedInput schema / properties / verify
      Added value: +{
+  "description": "kind=\"event\": {scheme: \"hmac-sha256\"|\"hmac-sha1\"|\"token\"|\"none\", header, secret (a host.secret_set name), prefix?, timestamp_header?, tolerance_s?, allow_unverified? (required true for scheme \"none\")}.",
+  "type": "object"
+}
    • changedInput schema / required
      Previous value: -[
-  "tool",
-  "schedule"
-]New value: +[
+  "tool"
+]
  5. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries full burden. It discloses the one-time return of {url, secret}, that each firing appears in host.runs.list, the signing/verification behavior for event and webhook, deduplication via dedupe_header, and specific error names (trigger_quota_exceeded, trigger_interval_too_short, trigger_invalid). This is exceptionally thorough for a mutating tool.

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 long but dense and efficiently packed into a single paragraph with semicolon-separated clauses. It front-loads the core schedule purpose, then lists alternatives. Given the complexity of four trigger kinds and 11 parameters, the length is justified and there is no redundant filler.

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 a tool with 11 parameters, 1 required, no output schema, and no annotations, this description covers all the essential behavioral aspects: kind-specific argument handling, verification schemes, error conditions, and the run visibility. An agent could correctly construct a call for any of the four trigger types without further documentation.

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 baseline is 3. The description adds meaningful cross-parameter semantics: it explains which params apply to which kind (args only for schedule/event, from for message, name for webhook), and clarifies the verify object structure and dedupe_header purpose. This goes beyond the schema's individual field descriptions.

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 and resource — 'Run a published tool on a cron schedule' — then expands to four explicit trigger kinds (schedule, event, message, webhook). It is unambiguous about what the tool does and naturally distinguishes it from sibling read/manage tools like host.trigger.get and host.trigger.list.

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?

It explains the conditions for each kind (e.g., 'kind=event' for webhook, 'kind=message' for tenant messages) and gives practical constraints (refuses quotas, interval limits). It does not explicitly contrast with manual triggering tools like host.trigger.fire or test, but the purpose is clear enough that an agent would know this is the creation path.

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

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