Skip to main content
Glama
Sign In
anythink-cloud

Anythink-MCP

Official
by anythink-cloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Workflows: integration add

workflows_integration_add

Add a provider integration step to a workflow using named flags instead of JSON params, with templated key=value inputs, credential source, and enable/disable control.

Instructions

Add an Integration step (Claude, OpenAI, Slack…) with named flags (no hand-written params JSON). The step runs one provider operation, such as claude generate-text, with inputs given as key=value pairs that accept {{ $anythink... }} templates; find provider and operation keys with integrations_get. credential_source chooses the credentials (system, current_user, connection with connection_id, or entity_field), and the step is created disabled unless enabled is set.

Input Schema

NameRequiredDescriptionDefault
nameNoStep display name (defaults to the step key)
inputNoOperation input as key=value (repeatable; values support {{templating}})
modelNoConvenience shortcut for the 'model' input (AI providers)
startNoSet as start step
inputsNoOperation inputs as a JSON object (merged with --input flags)
enabledNoEnable step immediately
providerNoIntegration provider key (e.g. claude, openai, slack). Required.
step_keyYesStep key (unique identifier, snake_case)
operationNoOperation key (see 'integrations get <provider>'). Required.
on_failureNoStep ID to execute on failure
on_successNoStep ID to execute on success
workflow_idYesWorkflow ID. Find it with workflows_list.
connection_idNoConnection ID (required when --credential-source is 'connection'; templatable)
credential_fieldNoCredential field path (required when --credential-source is 'entity_field')
credential_sourceNosystem | current_user | connection | entity_field (default: system)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.37
    • changedInput schema / properties / workflow_id / description
      Previous value: -"Workflow ID"New value: +"Workflow ID. Find it with workflows_list."
  2. Addedv0.2.27

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare the mutation safety profile (readOnly=false, destructive=false). The description adds genuinely new behavioral context beyond that: the step is created disabled unless `enabled` is set, and inputs accept {{ $anythink... }} templates. These are real traits not derivable from annotations or schema.

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-loads the core action and the 'no hand-written params JSON' framing before the credential detail. It is a dense single block but every clause carries information; only slight tightening is possible.

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?

For a 15-parameter creation tool with no output schema and full schema coverage, the description covers the essential unknowns: how inputs are expressed, where to find keys, credential sourcing, and the disabled-by-default behavior. Return-value explanation is unnecessary since no output schema exists.

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 meaning on top: it explains credential_source semantics (system/current_user/connection/entity_field), ties connection_id to the 'connection' source, and clarifies the key=value templating format for inputs. This is value beyond the schema text.

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?

States a specific verb (Add) and resource (an Integration step), and immediately disambiguates from the generic step-add sibling by naming the provider-operation model (claude generate-text). An agent can tell this apart from workflows_step_add without opening a schema.

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?

Explicitly routes the agent to `integrations_get` to discover provider and operation keys, and enumerates the credential_source options with their conditions. It does not, however, state when to prefer this over workflows_step_add, leaving one sibling distinction implicit.

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

Deploy Server

Other Tools