Skip to main content
Glama
Sign In
subtask

subtask

by tedin7
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

start_many

Starts several background jobs in one call, optionally linked as a dependency DAG or fanned out per item of a list, so agents can run parallel work with ordered waits.

Instructions

Start several jobs in one call. Items take start()'s arguments. With id + depends_on they form a group (grp-…) run as a DAG; subtask::summary in task/context_refs is replaced by the real job id. With Jev auto, the response includes advisory dependency checks; read them without treating them as permission. foreach=: one copy per item of the JSON list the parent writes to .subtask/fanout.json ({{item}} in task), max 8; dependents wait for every copy. after='any': start when one parent succeeded.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tasks": "<tasks>"
    },
    "name": "start_many"
  }
}

Input Schema

NameRequiredDescriptionDefault
tasksYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden and does disclose meaningful behavior: DAG groups, id substitution, advisory Jev checks, foreach fanout with max 8, and dependency waiting. It does not describe permissions, side effects, error behavior, or the overall response shape beyond the Jev-auto advisory checks.

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 front-loaded with "Start several jobs in one call" and then adds dense but relevant behavioral details. It is appropriately concise for a complex batch/DAG tool, though some jargon (Jev auto, grp-…) and formatting make it denser than ideal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (batch start, DAG dependencies, foreach fanout, Jev auto checks) with no annotations or output schema. The description covers many behaviors, but it omits return values, authorization, error handling, and complete task schema details. It is therefore only partially complete for an agent to invoke safely and 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 description coverage is 0%, so the description must compensate for the single complex tasks parameter. It does add substantial meaning for item fields, including start() arguments, id/depends_on grouping, subtask placeholders, foreach, and after='any'. It still leaves the top-level tasks structure minimally specified, but adds strong item-level semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: "Start several jobs in one call." It also distinguishes itself from the singular sibling by explicitly referring to start()'s arguments for each item. However, it never names the alternative or explicitly contrasts when to use start versus start_many.

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

Usage Guidelines3/5

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

Usage is implied by "Start several jobs in one call" and by the detailed notes on groups, depends_on, foreach, and after='any'. There is no explicit when-to-use/when-not-to-use guidance versus the sibling start tool.

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