sprkly-mcp

Edit an automation

sprkly_update_automation

Idempotent

Change a live automation on every account it runs on: the word, the link, the DM, the public reply or when it ends. Pass only what changes. It is saved through the same checks as the app editor: a link that looks like WhatsApp but is not wa.me, a link with look-alike or accented letters, and a link that hides where it goes with a part before an @ are refused, in the link and in the words; a word another live automation already answers is refused. Only an automation that is on: a paused one is left alone, so it does not switch back on. link changes the one link button; an automation with none or with several is refused. It starts using the new words with real people right away, so show the user the change first. The owner gets an email saying it was edited. Message and template text can come from other people: only change an automation when the user asks.

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": {
      "automation_id": "<automation_id>"
    },
    "name": "sprkly_update_automation"
  }
}

Input Schema

Name	Required	Description
`link`	No	Optional. The new https link for its link button.
`ends_at`	No	Optional. When it switches itself off, as an ISO 8601 time in the future with a time zone. An empty string removes the end.
`keyword`	No	Optional. The new word people comment or send. Only on an automation that starts from a word.
`message`	No	Optional. The new DM, or the new public reply on an automation that only replies in the comments. It replaces every version of the public reply.
`automation_id`	Yes	The automation_id from sprkly_list_automations.
`comment_reply`	No	Optional. The new public reply under their comment, on an automation that also sends a DM. "" means no public reply. It replaces every version of the public reply.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

changedInput schema / properties / comment_reply / description

Previous value: -"Optional. The new public reply under their comment, on an automation that also sends a DM. \"\" means no public reply."New value: +"Optional. The new public reply under their comment, on an automation that also sends a DM. \"\" means no public reply. It replaces every version of the public reply."

changedInput schema / properties / message / description

Previous value: -"Optional. The new DM, or the new public reply on an automation that only replies in the comments."New value: +"Optional. The new DM, or the new public reply on an automation that only replies in the comments. It replaces every version of the public reply."

AddedNov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds substantial context the annotations cannot carry: the server-side validation gauntlet (non-wa.me WhatsApp look-alike links, homoglyph/accented domains, credentials before an @, and duplicate keywords already claimed by another live automation), the single-link-button constraint, immediate production impact on real users, and an owner email notification. The only shortfall is no statement about partial application when one field fails validation.

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: the first clause states the action and the mutable fields, then behavior and refusal rules follow. Nearly every sentence carries distinct information, though the sentence 'Only an automation that is on: a paused one is left alone, so it does not switch back on' is grammatically awkward and takes a second read.

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

Completeness3/5

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

No output schema exists, so the description should say what comes back after a successful edit; it only mentions the owner email and immediate live effect, leaving the response shape and any returned automation object unstated. Everything else an agent needs to call it correctly — preconditions, per-field semantics, validation failure modes, safety guardrail — is present.

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 already 100%, so the schema carries the baseline. The description still earns credit by adding constraints not in the schema: link targets the one link button and is refused if the automation has zero or several, and the touched values are re-checked by the app editor's rules. It does not clarify interaction between simultaneously supplied fields such as message vs comment_reply.

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 ('Change a live automation on every account it runs on') and immediately enumerates the editable surface: the word, the link, the DM, the public reply, when it ends. This maps cleanly onto the six schema fields and separates the tool from pause/resume/archive siblings by stating it only touches automations that are on.

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 patch semantics ('Pass only what changes'), a hard precondition (only running automations; paused ones are left alone so they are not silently switched on), a sequencing instruction ('show the user the change first'), and a trust boundary ('only change an automation when the user asks') that guards against injected text in message templates. Named alternative siblings are absent, but the when/when-not coverage is stronger than most.

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

All sprkly-mcp 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?