Skip to main content
Glama

Create automation

create_automation

Configure Instagram comment-to-DM automations by choosing an account, trigger type, and message template with {{handle}} and {{commentText}} tokens.

Instructions

Create a comment→DM automation. Required: name, igAccountId (from list_ig_accounts), triggerType, templateText. templateText supports {{handle}} and {{commentText}} tokens. Advanced/paid options are left at their server defaults.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
dailyCapNo
actionTypeNo
igAccountIdYes
triggerTypeYes
templateTextYes
excludeKeywordsNo
includeKeywordsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=false, so the description carries most of the behavioral burden. It usefully discloses that advanced/paid options are left at server defaults, but says nothing about error behavior, permission requirements, or whether creation is idempotent.

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?

Four short sentences with no filler, front-loaded with the core purpose and then the requirements. Nothing is repeated from the schema verbatim; the sentences each add something.

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?

For an 8-parameter mutation tool with no output schema, the description is serviceable but incomplete: it omits the actionType/dailyCap/keyword options and does not say what is returned (e.g., the new automation id) for follow-up calls.

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 description coverage is 0%, so the description must compensate, and it covers the four required fields plus the igAccountId source and the {{handle}}/{{commentText}} template tokens. It leaves the four optional params (actionType, dailyCap, includeKeywords, excludeKeywords) and both enums unexplained.

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?

States a specific verb and resource with a distinguishing qualifier ('comment→DM automation'), so an agent can separate it from create_broadcast and update_automation. It does not name a sibling explicitly, but the resource plus trigger scope 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It lists the required parameters and points the agent to list_ig_accounts as the source of igAccountId, which is a real workflow hint. However, there is no when-to-use vs when-not guidance, nor any mention of how this differs from update_automation or when a new automation is appropriate.

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