Skip to main content
Glama
respanai

Respan MCP Server

Official
by respanai

create_workflow

Build custom monitoring, automation, and export workflows with conditional logic, aggregations, and notifications to respond to LLM events.

Instructions

Advanced low-level workflow creation. Prefer create_automation_workflow, create_monitor_workflow, or create_export_workflow for the three product workflows because those tools enforce product-specific inputs.

TYPES:

  • "monitors": Aggregation + threshold monitoring with notifications (Monitors page)

  • "automations": Triggered actions on log/trace events (Automations page)

  • "exports": Scheduled, continuous request-log exports. Requires trigger_event_type="scheduled", schedule_cron, and an export task.

  • "evaluators": Evaluator pipelines. Prefer create_evaluation_pipeline when wrapping graders.

  • "reports" and "ingests": Backend-supported advanced workflow families.

TRIGGER EVENT TYPES:

  • "request_log": Fires on every logged LLM request

  • "trace_completed": Fires when a trace finishes

  • "customer_budget_limit_reached": Fires on budget breach

  • "credit_low_balance_threshold_reached": Fires on low credit balance

  • "spend_cap_warning_threshold_reached": Fires at the spend-cap warning threshold

  • "limit_policy_soft_triggered" / "limit_policy_hard_triggered": Fires for limit-policy events

  • "on_eval_result_ingested": Fires when eval score is recorded

  • "custom_event": Fires for a custom event

  • "scheduled": Runs on a UTC cron schedule. Required for export workflows.

  • "eval_only": No trigger, for evaluator pipelines used in experiments

TASK TYPES:

  • condition: Filter/gate. Config: { condition_policy: { "event.": { operator, value } }, on_true: "continue", on_false: "stop" } Field paths use namespace: event.cost, event.model, event.status, state.. Operators: "in" (categorical), "gte"/"lte"/"gt"/"lt" (numeric), "icontains"/"startswith" (text)

  • aggregation: Time-window metrics. Config: { time_step_minutes: 5, metrics: [{ field_name: "event.cost", aggregation_function: "sum", output_field_name: "cost_sum" }] }

  • notification: Alert. Config: { severity: "high", message_template: "Cost: ${{state.agg.cost_sum}}" } Use {{variable}} for template variables.

  • webhook: HTTP callback. Config: { webhook_url: "https://...", source: "event" }

  • eval: Advanced callers must put generation_method at task root and supply evaluator_id plus the method-specific llm_config/code_config/human_config in config. Prefer create_automation_workflow for automatic evaluator hydration.

  • ingest: Save to dataset. Config: { target_type: "dataset", target: { dataset_id: "" } }

  • sampling: Random filter. Config: { rate: 0.1 } (10% of events)

  • compute: Arithmetic on upstream outputs. Config: { function: "ratio", inputs: [{ source: "state.", field: "" }] }

  • export: Append scheduled request logs to the export workflow output. Config: { filters?, include_fields?, is_inline_results?: boolean, sample_percentage?: number }.

  • switch: Multi-branch routing. Config: { cases: [{ condition_policy: {...}, target: "" }], default: "" }

TASK CHAINING: The backend auto-chains sequential tasks when next is omitted. Set next explicitly for non-linear routing or an intentional target. Task ordering: gates (condition, sampling) → aggregation → actions (notification, webhook, eval, ingest).

EXAMPLE - Cost spike monitor: { "name": "Cost spike monitor", "type": "monitors", "trigger_event_type": "request_log", "tasks": [ { "id": "agg", "type": "aggregation", "label": "Cost sum (5m)", "next": "check", "config": { "time_step_minutes": 5, "metrics": [{ "field_name": "event.cost", "aggregation_function": "sum", "output_field_name": "cost_sum" }] } }, { "id": "check", "type": "condition", "label": "Cost >= $1", "next": "notify", "config": { "on_true": "continue", "on_false": "stop", "condition_policy": { "state.agg.cost_sum": { "operator": "gte", "value": 1 } } } }, { "id": "notify", "type": "webhook", "label": "Cost alert", "config": { "webhook_url": "https://example.com/respan-monitor-alerts", "source": "event" } } ] }

EXAMPLE - Hourly export workflow: { "name": "Hourly request-log export", "type": "exports", "trigger_event_type": "scheduled", "schedule_cron": "0 * * * *", "tasks": [ { "id": "export_logs", "type": "export", "label": "Export request logs", "config": { "include_fields": ["timestamp", "model", "input", "output", "cost"], "is_inline_results": false, "sample_percentage": 100 } } ] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoWorkflow name.
typeYesBackend workflow family type.
tasksNoArray of task definitions. Gates first (condition, sampling) → aggregation → actions (notification, webhook, eval, ingest, export).
is_starredNoStar/bookmark this workflow.
descriptionNoWorkflow description.
schedule_cronNoUTC five-field cron expression. Required for scheduled workflows; minimum interval is five minutes.
trigger_event_typeNoEvent that triggers the workflow.
Behavior5/5

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

With no annotations provided, the description carries the full behavioral disclosure burden and does so thoroughly. It reveals backend auto-chaining when 'next' is omitted, imposes task ordering (gates → aggregation → actions), and documents trigger event types and task configs in detail. It also calls out special requirements, such as exports needing trigger_event_type='scheduled' and schedule_cron, making internal behavior transparent.

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 the complexity of the tool justifies the length and it is well-structured with clear headers for TYPES, TRIGGER EVENT TYPES, TASK TYPES, TASK CHAINING, and examples. It is front-loaded with the most important guidance: prefer specialized tools for product workflows. A small deduction is warranted because some sections could be tighter, but every block earns its place.

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 low-level creation tool with 7 parameters, no output schema, and no annotations, the description is exceptionally complete. It covers all workflow families, all trigger event types, detailed task configs, chaining rules, ordering constraints, and two full JSON examples. An agent could construct a correct workflow based solely on this description without consulting external documentation.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It enumerates valid values for 'type' and 'trigger_event_type', defines each task type with its config shape and operators, and explains task chaining semantics. The examples demonstrate how parameters like 'schedule_cron', 'tasks', and 'config' compose into real workflows, which is far beyond the schema's brief property descriptions.

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 states the tool's role as 'Advanced low-level workflow creation' and distinguishes it from sibling tools by explicitly recommending create_automation_workflow, create_monitor_workflow, and create_export_workflow for product-specific workflows. It also disambiguates 'evaluators' by directing users to create_evaluation_pipeline when wrapping graders. This gives a specific verb, resource, and scope while separating it from adjacent tools.

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?

The description provides explicit when-to-use guidance: 'Prefer create_automation_workflow, create_monitor_workflow, or create_export_workflow' for the three product workflows because those enforce product-specific inputs. It also says 'Prefer create_evaluation_pipeline when wrapping graders' and notes advanced callers should use create_automation_workflow for automatic evaluator hydration. This is clear exclusionary and alternative-tool guidance.

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/respanai/respan-mcp'

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