Skip to main content
Glama

sprkly-mcp

Import an auto reply template

sprkly_import_automation_template

Read an auto reply template, and optionally set it up. With no profile_id NOTHING is written: the template is checked and handed back, which is the safe first call. With a profile_id the automation is created, and it goes live when the trigger can be satisfied. A trigger that watches one post (a keyword on a post, or every comment on a post) needs post_id as well. Without one it saves as a draft that sends nothing until a post is chosen. A keyword on any post and a Profile DM need no post_id. A template that DMs every commenter on the whole account is turned off and is refused. Needs a connected Instagram account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
post_idNoThe published post to watch. Only for a trigger that watches one post. Leave it out for a keyword on any post or a Profile DM.
templateYesThe template, as an object or as the file text.
profile_idNoThe Instagram account to set it up on. Leave this out to only check the template.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / post_id / description
      Previous value: -"The published post to watch. Needed for a keyword or every-comment trigger."New value: +"The published post to watch. Only for a trigger that watches one post. Leave it out for a keyword on any post or a Profile DM."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Far beyond the annotations, the description discloses what actually gets written, the draft-vs-live state transition, that certain account-wide DM templates are refused, and that a connected Instagram account is required. This is exactly the mutation/authorization/rate behavior an agent needs and annotations alone would not provide.

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?

The two-mode behavior is front-loaded ('With no profile_id NOTHING is written'), and each subsequent sentence handles a distinct trigger case. It is dense but every sentence carries a rule; only slight tightening would help.

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 compensates by explaining that the check-only path hands the template back, and it covers the draft/live states and refusal case. For a nested-object, mutating tool, the coverage of behavior and prerequisites is complete.

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 adds genuine conditional meaning: it explains when post_id is required (single-post triggers) versus optional (keyword on any post, Profile DM), and clarifies profile_id as the write-enabling switch. It goes beyond restating the schema fields.

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?

The description states a specific verb (import/read) and resource (auto reply template), and lays out the two modes (check-only vs create). It does not name or contrast with the nearby siblings sprkly_create_automation_from_template or sprkly_export_automation_template, so the agent must infer the distinction, but the operation itself is unambiguous.

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?

It gives explicit conditional guidance: omitting profile_id is framed as 'the safe first call', and the post_id requirement is spelled out per trigger type. It stops short of naming alternative tools to reach for, but the when-to-use conditions are clear and actionable.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources