Skip to main content
Glama

Groundbase

workflows_create

Create a workflow. trigger_type is one of "entity_event" (fires on contact.created etc.), "scheduled" (cron/one-time), "inbound_webhook" (when a Groundbase inbound webhook receives a POST), or "manual" (only fired by workflows_run_now). For entity_event, set trigger_event to e.g. "contact.created", "deal.stage_changed", "task.completed". For scheduled, pass trigger_config like { recurrence: "one_time"|"daily"|"weekly"|"hourly", run_at?, time_of_day?, days_of_week?, minute_of_hour?, timezone? }. For inbound_webhook, trigger_event is the inbound webhook id from inbound_webhooks_list. Steps run sequentially. Step shapes: Each step is { type, config: { ...props } } — the per-type props below go INSIDE config, e.g. { "type": "create_note", "config": { "body": "hi" } } (flat props on the step are also accepted). The server validates on save and answers 400 INVALID_WORKFLOW listing every problem — unknown step type or operator, unknown trigger event, a schedule that would never fire, a bad timezone, a missing required prop, a webhook url on a private host — so read the message and fix the definition rather than retrying. Step types: send_sms { to?, body }; send_email { to?, subject, body_html?, body_text?, contact_id? } — blank to means the run's contact (on a deal, task or note, its contact); add_to_campaign { campaign_id } — puts the run's contact into an ONGOING campaign (enrolment_mode=ongoing, status sending) at its first step, under the campaign's rules; fails on a one-time or not-sending campaign; apply_tag { tag_name, entity_id?, entity_type? }; remove_tag { tag_name, entity_id?, entity_type? }; create_note { body, entity_type?, entity_id? }; create_task { title, description?, due_at?, due_in_days?, kind?, location?, contact_id? }; fire_webhook { url, method?, headers?, body? }; update_field { entity_type?, entity_id?, field, value } — restricted to a safe allow-list of native columns (first_name, last_name, email, phone, position, city, source, notes, primary_phone, company_id); set_custom_field { entity_type?, entity_id?, field_key, value } — writes to a custom field defined in Settings → Custom fields. field_key accepts "loan_amount" or "cf.loan_amount" (the cf. prefix is optional); delay { delay_seconds, stop_if? } — stop_if { reply?, meeting?, optout? } ends the run instead of continuing when, by the time the wait is over, the contact has replied (text or email), booked a meeting, or opted out since the run started. Only on a top-level wait longer than 60 seconds; branch { condition: { all|any: [{ field, op, value }] }, then: [Step], else: [Step] }. Templates supported in string fields: {{first_name}}, {{trigger.event}}, {{steps..output.}}. Step ids auto-generated as s_<8hex> if omitted; pass an explicit "id" to make {{steps.X.output.Y}} references stable across edits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name (required).
stepsYesOrdered list of steps. Each step is { type, config: { ...props } } — the per-type props below go INSIDE `config`, e.g. { "type": "create_note", "config": { "body": "hi" } } (flat props on the step are also accepted). The server validates on save and answers 400 INVALID_WORKFLOW listing every problem — unknown step type or operator, unknown trigger event, a schedule that would never fire, a bad timezone, a missing required prop, a webhook url on a private host — so read the message and fix the definition rather than retrying. Step types: `send_sms` { to?, body }; `send_email` { to?, subject, body_html?, body_text?, contact_id? } — blank to means the run's contact (on a deal, task or note, its contact); `add_to_campaign` { campaign_id } — puts the run's contact into an ONGOING campaign (enrolment_mode=ongoing, status sending) at its first step, under the campaign's rules; fails on a one-time or not-sending campaign; `apply_tag` { tag_name, entity_id?, entity_type? }; `remove_tag` { tag_name, entity_id?, entity_type? }; `create_note` { body, entity_type?, entity_id? }; `create_task` { title, description?, due_at?, due_in_days?, kind?, location?, contact_id? }; `fire_webhook` { url, method?, headers?, body? }; `update_field` { entity_type?, entity_id?, field, value } — restricted to a safe allow-list of native columns (first_name, last_name, email, phone, position, city, source, notes, primary_phone, company_id); `set_custom_field` { entity_type?, entity_id?, field_key, value } — writes to a custom field defined in Settings → Custom fields. field_key accepts "loan_amount" or "cf.loan_amount" (the cf. prefix is optional); `delay` { delay_seconds, stop_if? } — stop_if { reply?, meeting?, optout? } ends the run instead of continuing when, by the time the wait is over, the contact has replied (text or email), booked a meeting, or opted out since the run started. Only on a top-level wait longer than 60 seconds; `branch` { condition: { all|any: [{ field, op, value }] }, then: [Step], else: [Step] }. Templates supported in string fields: {{first_name}}, {{trigger.event}}, {{steps.<id>.output.<key>}}. Step ids auto-generated as s_<8hex> if omitted; pass an explicit "id" to make {{steps.X.output.Y}} references stable across edits.
isActiveNoDefaults to true (workflow starts active).
conditionNoOptional workflow-level filter — if present, the workflow is skipped (status=skipped) when this evaluates false. Shape: { all|any: [{ field, op, value }] } — `all` requires every clause, `any` requires one. Field paths: entity.<column> (entity.email, entity.source, entity.tags), cf.<field_key> for a custom field, trigger.event / trigger.entity_type / trigger.entity_id, and trigger.payload.<key> for what the event carried (e.g. trigger.payload.tag_name on tag.applied) — NOT payload.<key>, which never resolves; the server refuses it on save. Text ops: equals, not_equals, contains, not_contains, starts_with, ends_with. Presence ops: is_set, is_not_empty, is_empty, includes_tag. Numeric/date ops: greater_than, greater_or_equal, less_than, less_or_equal (numeric when both sides parse as numbers, else lexicographic, which sorts ISO timestamps correctly), plus older_than_days and newer_than_days which take a day count and compare against a date field such as entity.last_contacted_at.
descriptionNo
triggerTypeYesRequired.
triggerEventNoFor entity_event: the event name (e.g. "contact.created"). For inbound_webhook: the inbound webhook id.
triggerConfigNoFor scheduled triggers, the schedule shape. Otherwise null.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and excels: it discloses server-side validation with 400 INVALID_WORKFLOW, sequential step execution, side effects like add_to_campaign failing on non-ongoing campaigns, delay restrictions, update_field allow-list, and template resolution behavior. This goes well beyond a simple 'create' description.

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 densely organized with clear sections: trigger types, step types, templates, and step id generation. Every sentence contributes essential detail for a highly complex tool, though there is notable redundancy with the schema's steps description.

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?

For a complex create tool with no output schema, this description covers all important aspects: trigger configuration, complete step type inventory, validation error behavior, condition filtering, template syntax, and automatic id generation. Nothing an agent needs to correctly construct a valid workflow is missing.

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 high (88%), but the description adds concrete meaning beyond the schema: it specifies the trigger_config shape (recurrence, run_at, time_of_day, etc.), the triggerEvent semantics for inbound_webhook, and the ambiguity that field_key accepts 'loan_amount' or 'cf.loan_amount'. Some step details are duplicated from the schema, but the added parameter context is valuable.

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?

Starts with the specific verb+resource 'Create a workflow' and then details the trigger types and step types. It is clearly differentiated from sibling tools like workflows_update, workflows_get, and workflows_delete by focusing on creation.

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?

Provides clear context for when to use each trigger type and references workflows_run_now for manual triggers. It does not explicitly contrast with workflows_update or other alternatives, so it stops short of full when/not guidance.

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