Skip to main content
Glama

CTRL

by io.github.CTRLabs

ctrl_create_workflow

Create a CTRL workflow draft. ONE trigger + an ordered chain of up to 20 actions/conditions/utilities. Returns { workflowId, activateUrl }. Pass targetChain to pick which chain the workflow runs on — "base" (default, launchpads + Aerodrome + UniV4) or "ethereum" (UniV3 only, no launchpads, no clanker/zora). CRITICAL: call ctrl_get_block_catalog FIRST (with the same chain value) to discover field names — every key in trigger.config and chain[].config must exactly match catalog fields[].key. Populate EVERY field the user expressed intent for. For pool.created (Token Launch, Base-only) set launchpad (e.g. ["bankr"]), keywordIncludes ("ai,agent,claw"), keywordMatchMode "any", keywordCategories (["ai_agents"]), safetyEnabled true, safetyRejectHoneypot true, safetyMinScore 50. For cypher.swap set tokenIn ("ETH"), tokenOut ("{{trigger.tokenAddress}}"), tokenOutMode "dynamic", amount (ETH units, e.g. 0.005 — ASK USER if not specified), slippage (15 for snipes), and autoSell* if user wants an exit (autoSellEnabled true, autoSellMode "multiple", autoSellMultiplier 2, autoSellPercent 100, autoSellReceiveToken "USDC"). For notify.telegram set message with {{token}}/{{amount}}/{{txHash}} placeholders. Interview the user for missing critical fields (amount, exit strategy, keywords) — do not silently default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
chainYes
triggerYes
descriptionNo
targetChainNoChain to run the workflow on. Default: "base". "ethereum" disables launchpad-only blocks (pool.created/clanker/zora/bankr/flaunch) and UniV4/Aerodrome routing.

TDQS

A4.9/5.0
Behavior5/5

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

No annotations provided, so description carries full burden. Discloses creation behavior (draft, not activation), required prior discovery call, side-effect of creating a resource, and return structure. Also explains configuration requirements and constraints like max 20 items.

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?

Well-structured with clear sections and front-loaded purpose, but quite long (multiple paragraphs). Could potentially be slightly more concise while retaining essential details. Still efficient for the complexity.

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?

Given no output schema, description covers return values. Also explains dependencies (ctrl_get_block_catalog), constraints (max 20, required fields), and edge cases (different chains, missing fields). Complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (20%), but description extensively explains parameters: targetChain enum values, chain and trigger config passthrough, and specifics for block types (e.g., for cypher.swap: amount, slippage, autoSell*). Adds significant meaning beyond schema.

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?

Clearly states it creates a CTRL workflow draft, specifies one trigger plus chain of up to 20 actions/conditions/utilities, and mentions return value { workflowId, activateUrl }. Differentiates from siblings like ctrl_activate (activation) and ctrl_get_block_catalog (discovery).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Provides explicit when-to-use: call ctrl_get_block_catalog FIRST, use targetChain to select chain, gives detailed instructions for specific block types (pool.created, cypher.swap, notify.telegram), and advises to interview user for missing critical fields. Implicitly tells when not to use (e.g., not for activation).

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

All CTRL toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct operation: vault activation, workflow creation, manual firing, catalog retrieval, log reading, and vault status. No two tools have overlapping responsibilities.

Naming Consistency5/5

All tools follow a consistent 'ctrl_verb' pattern (e.g., ctrl_activate, ctrl_create_workflow), making it easy to infer functionality from the name.

Tool Count5/5

6 tools cover the essential operations for a workflow automation server without being excessive or sparse. The scope is well-defined.

Completeness4/5

The set covers core workflows (create, activate, trigger, monitor) but lacks explicit update/delete for workflows or vaults. This is a minor gap that can be worked around.

Resources