Skip to main content
Glama
AiBadgr

Badgr — GPU Compute for AI Agents Copy

Official
by AiBadgr

launch_agent_task

Starts an autonomous coding agent on a GitHub repository, runs a required verification command, and returns a job ID for polling results and costs.

Instructions

Launch an autonomous coding agent on a GitHub repository. The job is verified by running check. max_cost is REQUIRED (hard limit $5); max_runtime_minutes is REQUIRED (limit 60). Returns a job_id: poll with check_launch_task, and read the receipt when it finishes. Always confirm with the user before launching.

Input Schema

NameRequiredDescriptionDefault
agentNoclaude
checkYesShell command that must succeed for the task to count as done
max_costYesHard cost cap in USD (max 5)
repositoryYesGitHub repository URL (https://github.com/owner/repo)
instructionYesWhat the agent should do
max_runtime_minutesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses hard cost/runtime caps, that verification runs `check`, that a job_id is returned, and that user confirmation is required. It omits key side-effect details – whether the agent commits/pushes/opens PRs on the repo and what happens on failure or timeout – which matters for a mutating launch.

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?

Front-loaded with purpose, then verification, limits, return/workflow, and the confirmation rule – every sentence carries information an agent needs. No filler.

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?

Covers the launch-verify-poll-receipt lifecycle and the required-parameter emphasis, which is enough to invoke it correctly, and there's no output schema to explain. The gap is agent-selection guidance and failure/side-effect semantics for a tool that can mutate a repository.

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 67%. The description restates the max_cost and max_runtime_minutes constraints that the schema already enforces (maximum 5, maximum 60) rather than adding guidance. It says nothing about the `agent` enum (claude/codex/cline/...), its default, or how `repository`/`instruction` should be formed.

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 ('Launch an autonomous coding agent on a GitHub repository') plus the verification mechanism, and names the sibling (check_launch_task) used to follow up. An agent can tell exactly what this does relative to check_launch_task or the badgr_* tools.

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?

Gives a concrete workflow rule ('Always confirm with the user before launching') and explicitly routes follow-up polling to check_launch_task. It stops short of stating when NOT to use it (e.g. vs. run_workload or a specific agent choice), so it's not a full 5.

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