Skip to main content
Glama
Sign In
io.github.RohitYajee8076/backburner

io.github.RohitYajee8076/backburner

by RohitYajee8076
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

start_task

Start a shell command as a background task and receive its ID immediately, enabling long-running jobs to continue after the call returns.

Instructions

Start a shell command as a background task and return immediately.

Args: command: The shell command to run (e.g. "pytest -q" or "npm run build"). cwd: Working directory for the command. Defaults to the server's cwd. timeout_seconds: If set, the task is killed and marked 'timed_out' when it runs longer than this. Recommended for unattended jobs.

Returns the new task's id and initial status. The command keeps running after this call returns — use task_status / task_result to follow it.

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": {
      "command": "<command>"
    },
    "name": "start_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
cwdNo
commandYes
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: the command runs in the background, the call returns immediately, the task can be killed if it exceeds timeout_seconds, and a new task id and initial status are returned. This is sufficient transparency for the tool's behavior.

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?

The description is well-structured with a one-sentence summary, a clear Args block, and a follow-up note. Every sentence adds value, and the format makes it easy to scan and understand without unnecessary verbosity.

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?

The tool is simple with three parameters and no output schema, yet the description covers what is returned (task id and initial status), how the task continues to run, and how to follow up using sibling tools. This provides complete context for an agent to use the tool correctly.

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?

Schema description coverage is 0%, but the description provides detailed semantics for all three parameters: command is exemplified, cwd defaults to the server's cwd, and timeout_seconds causes the task to be killed and marked 'timed_out'. This fully compensates for the lack of schema 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 function: 'Start a shell command as a background task and return immediately.' It specifies both the verb and resource, and distinguishes itself from siblings by explaining follow-up with task_status/task_result, making it clear this tool initiates the task while others monitor or cancel.

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 explicitly tells the agent when to use this tool (to start a background command) and what to do after (use task_status / task_result to follow it). It also provides a specific guideline for timeout_seconds, recommending it for unattended jobs, which helps the agent decide when to set this parameter.

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