flayr

Update or turn on a comment-to-get trigger

update_growth_trigger

DestructiveIdempotent

[PUBLISHES to social accounts · publish scope] Changes a trigger; only the fields you pass change. active: true makes it reply to and DM real people from then on and needs the publish scope: confirm with the user first. active: false pauses it. (Wraps PATCH /api/v2/growth-triggers/{id}.)

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": {
      "id": "<id>"
    },
    "name": "update_growth_trigger"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`link`	No	http(s) URL behind {{link}}.
`name`	No
`active`	No
`dmText`	No	Private reply (Instagram and Facebook only; refused on an account of another platform).
`brandId`	No	A brand id (GET /api/v2/brands) or "personal"; default: the key owner's active brand. A brand-bound key is always pinned to its brand; any other value is 403.
`postIds`	No	Only comments on these posts; omitted = all posts.
`keywords`	No	Case-insensitive. exact = the whole comment; startsWith = its start; contains = anywhere (substring, so "hi" also matches "this").
`maxSends`	No	After this many sends, reply only overCapText.
`priority`	No	Higher is checked first; the first matching trigger wins.
`accountId`	No	A connected account id (GET /api/v2/accounts); omitted = every account of the brand.
`replyText`	No	Public reply. {{name}} = the commenter, {{link}} = `link` with UTM tags. Must not contain a keyword (it would trigger itself).
`campaignKey`	No	utm_campaign for {{link}}, and the campaign column of the logs.
`overCapText`	No
`delaySeconds`	No	Wait before replying; capped at 20 at send time.
`dmVariations`	No
`repeatPolicy`	No		once_per_commenter
`replyVariations`	No	Alternatives picked at random with replyText.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the bar is lower, yet the description still adds real value: it discloses that enabling the trigger will message real people, that the `publish` scope is required, that a user confirmation is expected, and that PATCH semantics mean omitted fields are untouched. It does not describe what the response contains or rollback behavior, keeping it short of a 5.

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?

Three tight sentences plus the endpoint wrapper. The scope/publish warning is front-loaded in brackets before any operational detail, and no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 18-parameter destructive mutation with no output schema, the description covers the risky dimension (live outreach, scope, confirmation) and the update semantics. It stops short of stating what the call returns or what happens to already-sent replies, which are minor omissions given the schema's richness.

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 67% and the schema already carries the rich per-parameter text (keywords matching, maxSends/overCapText, brandId pinning, delay cap). The description only adds meaning for `active`; it says nothing extra about the several undocumented fields (id, name, overCapText, dmVariations, repeatPolicy). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Changes a trigger; only the fields you pass change" states a specific verb plus resource and adds the partial-update semantic. It implicitly separates this from create_growth_trigger / delete_growth_trigger / get_growth_trigger via the verb, but never names those siblings explicitly.

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?

Gives a concrete conditional rule: `active: true` turns on live replying/DMing and requires the publish scope, with an explicit "confirm with the user first" gate; `active: false` pauses. What is missing is routing to alternatives (e.g., use create_growth_trigger to make a new one) and any note about which fields are safe to change.

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

All flayr 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?