Sliq

Remove trigger

remove_trigger

Removing a flow node's on_enter enactment un-arms that node — prospects entering it no longer enact until you re-arm it with add_trigger. To stop it firing while keeping its authored content, pause it with update_trigger(status='paused') instead. Dict with success, agent_id, and next_run_at. Read the agent's surviving triggers via get_agent_details.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "trigger_id": "<trigger_id>"
    },
    "name": "remove_trigger"
  }
}

Input Schema

Name	Required	Description	Default
`trigger_id`	Yes	ID of the trigger to remove (from the agent's trigger list).
`on_behalf_of`	No	A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / on_behalf_of / description

Previous value: -"An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
+}

Changed1 schema field changedSep 23, 2026

changedInput schema / properties / trigger_id / description

Previous value: -"ID of the trigger to remove (from the task's trigger list)."New value: +"ID of the trigger to remove (from the agent's trigger list)."

First observedSep 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description supplies the actual behavioral consequences the agent needs — surviving triggers keep running, the agent won't fire after the last one is removed, and a flow node's on_enter enactment becomes un-armed. The implied reversibility (re-arm with add_trigger) is consistent with destructiveHint=false, so no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and its consequence are front-loaded in the first two sentences, followed by the narrower flow-node case and the alternative. The summary/returns structure is compact and every sentence carries distinct information.

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 no output schema, the description still specifies the return shape (success, agent_id, next_run_at) and points to get_agent_details for verifying surviving triggers. For a two-parameter deletion tool, nothing an agent needs before or after the call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both trigger_id and on_behalf_of are already documented in the schema. The description repeats the 'by id' framing without adding format, lookup, or scoping detail beyond what the schema provides, making the baseline 3 correct.

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 first sentence gives a specific verb and resource with scope: 'Delete one trigger from its agent by id.' It is trivially distinguishable from add_trigger and update_trigger, which are named elsewhere in the text.

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?

It explicitly names two alternatives with the conditions that select them: pause via update_trigger(status='paused') to stop firing while keeping authored content, and re-arm via add_trigger. It also states the consequence of removing the last trigger, so the agent knows when this is the wrong call.

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?