Skip to main content
Glama
mondaycom

monday MCP Server

Official
by mondaycom

Create Automation

create_automation

Creates an automation on a monday board from a natural-language description. Specify the trigger, conditions, and actions to automate your workflow.

Instructions

Creates an automation on a monday board from a structured natural-language description.

Use this tool only when you know:

  • boardId

  • the user's intended trigger

  • at least one intended action

  • any details the user provided that are relevant to the trigger, conditions, or actions

The caller does not need to know the exact available automation blocks or their required fields. Describe the user's intent clearly — the tool will translate that intent into supported blocks and values.

If a required detail is missing from the user's request, ask for clarification before calling the tool.

If the tool returns status: "needs_clarification", present the unresolved fields to the user, gather answers, then call the tool again.

Describe the automation in this format:

Trigger: When Details: :

Conditions:

  • Only if Details: :

Actions:

  • : :

Rules:

  • Use one trigger.

  • Conditions are optional.

  • Multiple conditions mean AND.

  • Use one or more actions.

  • Do not use branching.

  • Use natural language, not block IDs or internal field names.

  • Actions may reference values from the trigger context, such as "{{item name}}", "{{creator}}", "{{status}}", "{{group}}", or "{{board}}".

Terminology:

  • Trigger: the event that starts the automation, such as "when a new item is created".

  • Conditions: optional requirements that must be true before actions run.

  • Actions: what the automation does when it runs.

Example:

Trigger: When a new item is created

Actions:

  • Send a notification: Recipient: John Snow Title: Important Update Message: The item "{{item name}}" was created.

  • Move the item to a group: Group: Top group

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userPromptYesStructured description of the automation to create.
boardIdYesThe numeric board ID as a string.
Behavior4/5

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

The description adds behavioral context beyond annotations: it explains that the tool translates natural language into supported blocks, may return 'needs_clarification' status, and that conditions are optional and multiple conditions imply AND. It does not contradict annotations (destructiveHint=false, idempotentHint=false). With annotations providing basic intent cues, this description adds valuable behavioral details.

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 description is long but well-structured with clear sections (purpose, usage guidelines, format, rules, terminology, example). It is front-loaded with the main purpose. While every part serves a purpose, it could be slightly more concise; however, the structure aids understanding.

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?

Given the complexity of creating automations (triggers, conditions, actions) and the lack of an output schema, the description adequately covers the input requirements, expected behavior, and potential responses (needs_clarification). It does not cover success return values, but the provided information is sufficient for an agent to select and invoke the tool correctly.

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 baseline is 3. The description adds significant meaning by providing a structured template for the 'userPrompt' parameter, including examples and rules for formatting. The 'boardId' parameter is simply described as 'numeric board ID as a string' in the schema, but the description confirms its usage context.

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?

The description clearly defines the tool's purpose: creating an automation on a monday board from a structured natural-language description. It specifies the verb 'creates', the resource 'automation', and the context 'monday board' and 'structured natural-language description'. This distinguishes it from sibling tools like 'list_automations' and 'manage_automations'.

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?

The description provides explicit guidance on when to use the tool: only when the agent knows boardId, the intended trigger, at least one action, and relevant details. It also states what the agent does not need to know (exact automation blocks) and advises asking for clarification if details are missing. However, it does not explicitly state when NOT to use the tool or mention alternative tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mondaycom/mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server