Argorant

Write the campaign subsequences

argorant_set_campaign_subsequences

Destructive

Replace a campaign's subsequences, the follow-up emails that start when a reply contains a keyword (up to 5). Use it for replies such as interested or send pricing that should get their own emails. For the main emails use argorant_set_campaign_emails, and to turn one subsequence off or on by itself use argorant_set_subsequence_enabled. When a reply matches, that person leaves the main emails and gets the first matching subsequence, in list order, in the same thread. A keyword also matches in capitals, as a plural, with a small typo or inside a short sentence, so interested matches Interested!, intrested and very interested, but never interesting. A keyword after not or no, as in not interested, never counts, quoted text in a reply is ignored, and replies asking to stop never start one. An empty list removes them all. The first email goes out delay_days after the reply, where 0 means the next sending window, with the subject 'Re: {{thread_subject}}' unless you set one. More in the docs at https://docs.argorant.com/docs/agents/tools#campaigns

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": {
      "campaign_id": "<campaign_id>",
      "subsequences": "<subsequences>"
    },
    "name": "argorant_set_campaign_subsequences"
  }
}

Input Schema

Name	Required	Description	Default
`campaign_id`	Yes	The campaign's id, from argorant_list_campaigns.
`subsequences`	Yes	The full list in order, as [{name, keywords, emails, enabled?}]. keywords holds 1 to 10 words or short phrases. emails holds 1 to 8 emails in the shape argorant_set_campaign_emails takes (subject?, body, delay_days?, same_thread?, variants?). Left out, enabled keeps a saved subsequence's state and a new one starts on.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say non-read-only and destructive; the description goes well beyond by disclosing that this is a full replace, that an empty list removes all subsequences, and that a matched replier leaves the main emails and receives the first matching subsequence in list order within the same thread. It also scopes matching precisely (case, plurals, typos, negation, quoted text, stop requests), which is behavior no structured field conveys.

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 purpose and alternatives before the finer matching rules, and every clause is on-topic. It runs long and the keyword-matching detail could live behind the docs link it already provides, but the density is defensible for a destructive bulk-replace tool with subtle matching semantics.

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 destructive replace with two parameters and an output schema, the description covers the replacement scope, the empty-list case, matching behavior, timing, and defaults. An agent has enough to call it correctly and to anticipate the consequences of a wrong call.

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?

With 100% schema coverage the schema already documents campaign_id and the subsequence object shape, so the baseline is 3. The description adds real meaning on top: delay_days semantics ('0 means the next sending window'), the default subject template, and the default for omitted 'enabled'. It does not restate the keyword/email count limits the schema list, which is fine.

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?

Opens with a specific verb and resource ('Replace a campaign's subsequences'), immediately defines the resource in plain terms ('the follow-up emails that start when a reply contains a keyword') and bounds it ('up to 5'). It is unmistakably distinct from argorant_set_campaign_emails and argorant_set_subsequence_enabled, which it names.

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?

Explicitly routes the agent: main emails go to argorant_set_campaign_emails, single toggling goes to argorant_set_subsequence_enabled, and this tool is the bulk replacement path. The alternative-and-condition pairing is exactly what an agent needs to choose between three similar-sounding write tools.

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

All Argorant 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.