Sliq

Add Trigger

add_trigger

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.

The same goal-sync obligation update_trigger carries applies to creating one: a new scheduled trigger adds recurring behavior the goal doesn't yet describe, and the goal is injected into every turn on this agent. After this call, name what the new trigger does and how often via update_agent(agent_id=..., goal=...) in the same turn. A flow's per-node on_enter triggers are already covered by the goal's sequence description and need no separate mention.

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). 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`trigger`	Yes	The trigger to add. In its prompt, name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat.
`agent_id`	Yes	ID of the agent to add the trigger to

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 25, 2026

changedInput schema / properties / trigger / description

Previous value: -"The trigger to add"New value: +"The trigger to add. In its prompt, name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat."

Changed3 schema fields changedSep 23, 2026

addedInput schema / properties / agent_id

Added value: +{
+  "description": "ID of the agent to add the trigger to",
+  "type": "integer"
+}

removedInput schema / properties / task_id

Removed value: -{
-  "description": "ID of the task to add the trigger to",
-  "type": "integer"
-}

changedInput schema / required

Previous value: -[
-  "task_id",
-  "trigger"
-]New value: +[
+  "agent_id",
+  "trigger"
+]

First observedSep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false/destructiveHint=false. The description adds substantial behavior beyond that: new code executes on the trigger's next firing, a goal-sync obligation via update_agent must happen in the same turn, one on_enter per node limit, the paused-agent warning, and the credential/context implication that a later run doesn't see this chat.

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?

Front-loaded with the purpose and the sibling preference, then layered detail. It is long, but for a tool with six trigger variants and cross-tool obligations every sentence is load-bearing; only mild compression is possible.

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?

A complex, multi-variant mutation tool with no output schema but an inline <returns> block describing success, agent_id, trigger_id, next_run_at, the trigger dict, and the paused warning. Combined with the annotations and detailed usage rules, an agent has everything needed to invoke it correctly.

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 baseline is 3, but the description meaningfully extends it: the on_enter trigger's prompt holds only extra instructions while the message itself goes in message_templates, and prompts should name outside resources by the identifier the tool takes rather than by title. This is real semantic guidance beyond the schema.

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 ('Add a trigger to an existing agent') and immediately scopes it against the sibling it is not ('Prefer this over creating a new agent'). An agent can distinguish it from create_agent, update_trigger, and define_sequence without opening any schema.

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?

Gives explicit when-to-use (schedule follow-ups on an agent with context), when-not (prefer this over creating a new agent), the alternative for editing (use update_trigger if a node already has an on_enter), and a mandatory prerequisite (get_skill_guide('trigger_code') before writing code). Routing is unambiguous.

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

All Sliq tools Inspect

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

Need Help?