Skip to main content
Glama

TaScan

by io.github.snowbikemike
OverviewDiscussionsAdmin

tascan_control_fanout

DestructiveIdempotent

Control a running fan-out (POST /coord/fanouts/:id/control). pause holds every unclaimed seat and stops re-firing; resume releases them; cancel supersedes every unclaimed task and closes once quiet; close_barrier drops unsettled (or named exclude_seats) seats and forces the synth now; retry_synth mints a new synth revision from the stored inputs of the current synth when every failed run is input_ref_mismatch, refused otherwise (not_synthesizing, no_synth_task, no_failed_runs, not_input_ref_mismatch). No amend or answer yet. Every action first records a signed control completion as the system worker of this org, never as another org identity. idempotency_key replays the prior outcome (replayed true) and applies nothing twice; a replayed resume after a later pause stays paused. Refused fanout_closed once the roll-up has closed. Requires agent:dispatch:code.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYespause, resume, cancel, close_barrier or retry_synth. No amend, no answer (phase 1).
reasonNoOptional free-text reason (<= 4000 chars), recorded on the control child's completion.
fanout_idYesFan-out id (UUID) — the T_F root.
exclude_seatsNoclose_barrier only: 1-based seat numbers to drop from the barrier instead of waiting for them to settle.
idempotency_keyNoOptional replay key (<= 200 chars). The same key returns the prior outcome (replayed:true) and applies nothing a second time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"pause, resume, cancel or close_barrier. No amend, no answer (phase 1)."New value: +"pause, resume, cancel, close_barrier or retry_synth. No amend, no answer (phase 1)."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "pause",
-  "resume",
-  "cancel",
-  "close_barrier"
-]New value: +[
+  "pause",
+  "resume",
+  "cancel",
+  "close_barrier",
+  "retry_synth"
+]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that every action records a signed control completion as the system worker of this org (never another org identity), the exact idempotency replay semantics including the subtle 'replayed resume after a later pause stays paused' case, the fanout_closed refusal condition, and the required agent:dispatch:code permission. These are precisely the destructive/auth/replay details an agent needs.

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?

Purpose and action semantics are front-loaded, and each sentence carries information (refusals, replay, auth, identity). It is dense and somewhat run-on in the middle, but there is little waste for the amount of behavior it must convey.

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?

Despite no output schema, the description explains observable outcomes (replayed:true on replay, enumerated refusal reasons like fanout_closed and not_synthesizing) and the permission requirement. An agent has everything needed to invoke and interpret results correctly.

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 genuine meaning over the terse schema: it explains what each enum action does to seats and tasks, clarifies exclude_seats as 'named exclude_seats' for close_barrier, and elaborates idempotency_key replay behavior. The added semantics exceed what the schema documents.

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+resource ('Control a running fan-out') with the underlying endpoint, and enumerates exactly what each of the five actions does (pause holds seats, resume releases, cancel supersedes, close_barrier forces the synth, retry_synth mints a revision). This clearly distinguishes it from sibling lifecycle tools like create_fanout and get_fanout.

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 description gives per-action conditions for use and explicitly rules out others ('No amend or answer yet'; retry_synth 'refused otherwise' with enumerated refusal reasons). It lacks an explicit routing statement toward siblings, but the action-level conditions are detailed enough for correct invocation.

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

All TaScan toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources