Skip to main content
Glama
Sign In

neonloops

by com.neonloops
OverviewDiscussionsAdmin

Workflows: list

workflows_list
Read-only

Lists the neonloops workflows this connection reaches, most recently changed first: name, status, project, publish state and timestamps, with no steps. Use it to find a workflow's id, to see what already runs on a schedule or when an app event happens, or to check what a project holds before creating another. It reads every workflow the token reaches, or one project's with project_id; an unknown or unreachable project is refused. For a workflow's steps and versions use workflows_get, and for what a workflow has run use runs_list.

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": "workflows_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idNoOnly this project's workflows, by id as workspace_whoami lists it. Omit to list every workflow in the workspace that this token reaches.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Narrow to one project's workflows. Omit to list every workflow in the workspace this token reaches."New value: +"Only this project's workflows, by id as workspace_whoami lists it. Omit to list every workflow in the workspace that this token reaches."
  2. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare a read-only, closed-world, non-destructive operation, and the description still adds real value: default sort order, exact field set returned, the absence of steps, and token-scoped coverage ("every workflow the token reaches"). The error behavior for an unknown or unreachable project is also disclosed; only volume/pagination behavior is left unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with what is returned and in what order, then usage, then scoping and sibling routing. No filler and no repetition of the title.

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?

No output schema exists, so the description carries the return-shape burden and does so explicitly (name, status, project, publish state, timestamps, no steps). For a single-param read tool with full annotation coverage, nothing an agent needs to call it correctly 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 100%, so the baseline is 3, but the description adds meaning beyond the schema: omitting project_id means token-wide listing, and a project_id that is unknown or unreachable is refused. That error semantics detail is not present in the schema itself.

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 ("Lists the neonloops workflows this connection reaches") plus ordering, returned fields, and an explicit exclusion ("with no steps"). It is immediately distinguishable from workflows_get and runs_list, which are named.

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?

Gives three concrete use cases (find an id, see what runs on a schedule or app event, check a project's contents before creating another) and routes to alternatives: workflows_get for steps and versions, runs_list for execution history. When-to-use and when-not-to-use are both covered.

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

All neonloops toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources