Skip to main content
Glama
Sign In
Swipium

Swipium

by GeroPalombo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check a flow

qa_flow_check
Read-only

Validates flow YAML or a flow name without running it, reporting schema errors at the offending step and warnings, and supports CI preflight and plan-mode backend preview.

Instructions

Validate a flow (flow name/path or flowYaml) without running it: schema errors with the offending step, plus warnings. Per-backend preview: qa_flow_run mode:"plan".

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "qa_flow_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
ciNoAdd CI preflight warnings (missing variables, forbidden mutating steps).
flowNoFlow name under .swipium/flows, or a path to a .yaml file.
flowYamlNoInline flow YAML (instead of a file).
platformNoAuthoring target for platform-aware warnings.
sessionIdNo
projectRootNoAbsolute app root.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description usefully adds that the flow is not executed and that output consists of schema errors tied to the offending step plus warnings. It does not disclose whether validation is static-only or the cost/latency of running it, but the core behavior is disclosed.

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?

A single front-loaded sentence with no filler; the purpose and return shape come first. It is slightly telegraphic — the trailing 'Per-backend preview: qa_flow_run mode:"plan"' reads as a fragment and could be clearer, but nothing is wasted.

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 6-parameter, zero-required validation tool with no output schema, the description conveys both what is checked and what comes back (per-step errors and warnings). Gaps are minor: the meaning of projectRoot/sessionId and the shape of a successful result are left to the schema.

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

Parameters3/5

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

Schema coverage is 83%, with flow, flowYaml, platform, ci, and projectRoot all described in the schema. The description only restates the three input forms and never explains ci, platform, or the undocumented sessionId, so it adds little beyond the schema baseline.

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 and resource ('Validate a flow') with the key qualifier 'without running it', and explicitly names the input alternatives (flow name/path or flowYaml). It also distinguishes itself from qa_flow_run by noting that a per-backend preview requires that sibling's plan mode.

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 'without running it' clause plus the pointer to qa_flow_run mode 'plan' gives the agent a clear use case and an explicit alternative for the deeper check. There are no stated exclusions or prerequisites (e.g. whether projectRoot is needed for name-based lookups), so it stops short of full when/when-not guidance.

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