Skip to main content
Glama

post_task_auto

Automatically route each task to the least-loaded agent with all required capabilities. Queue if no agent is online, then auto-assign when a capable agent appears.

Instructions

Auto-route a task to the least-loaded capable agent (v2.0).

When to use: when you know the required capabilities but do not want to hard-code a specific assignee, load balances across the fleet. Prefer post_task when the assignee is intentional. Prefer broadcast for non-tracked notifications.

Behavior: picks the agent with the smallest accepted-task backlog whose capability set is a superset of required_capabilities. Tie-break: freshest last_seen. If no live agent qualifies, the task enters status='queued' and is auto-assigned the first time a capable agent calls register_agent (the assignment is included in that response's auto_assigned). By default the sender is excluded from routing, set allow_self_assign=true to opt in (v2.1).

Returns: { success: true, task_id, status: 'posted' | 'queued', assigned_to: string | null, routed: boolean, candidate_count, required_capabilities, note }. routed=true only when an agent matched at post time; routed=false with status='queued' is the no-match path that auto-resolves on next register.

Errors: AUTH_FAILED, PAYLOAD_TOO_LARGE, RATE_LIMITED.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromYesRequester agent name
titleYesShort task title
priorityNoTask prioritynormal
agent_tokenNoYour agent token (from register_agent response). Optional here — also resolvable from RELAY_AGENT_TOKEN env or X-Agent-Token header.
descriptionYesFull task description (max 64KB by default)
allow_self_assignNov2.1: opt-in flag to let the sender self-assign the task when they match the required capabilities. Default false — sender is excluded from routing so auto-routed work reaches peers.
required_capabilitiesYesCapabilities the assigned agent must have (ALL must match). Also used to auto-assign from the queue when a capable agent registers later.
Behavior4/5

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

No annotations are provided, so the description carries the burden. It thoroughly discloses the routing algorithm (smallest accepted-task backlog, superset matching, freshest last_seen tie-break), the queued/auto-assign path via register_agent, sender exclusion, and the return contract. It also lists error codes. Minor gap: no mention of rate-limit specifics or auth requirements beyond token resolution.

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?

Well-structured with labeled sections (When to use, Behavior, Returns, Errors), front-loaded with the purpose. Each sentence earns its place, and the labeled sections make scanning efficient despite its length.

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?

Complete for a routing tool with 7 params at 100% schema coverage. The no-output-schema gap is compensated by a detailed return contract, and the queuing/auto-assignment behavior is fully explained. The v2.0/v2.1 versioning is clearly documented.

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 baseline is 3. The description adds value by clarifying `allow_self_assign` semantics (v2.1 opt-in, sender exclusion rationale) and `required_capabilities` dual role (routing plus queue auto-assignment). It also explains the return-value semantics for `routed`/`queued` paths beyond what the schema provides.

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?

Description states specific verb+resource ('auto-route a task to the least-loaded capable agent') with versioning (v2.0). It distinguishes from siblings by naming `post_task` (intentional assignee) and `broadcast` (non-tracked notifications). Clearly differentiates its auto-routing role from the other task tools.

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?

Explicit 'When to use' section states the tool is for when capabilities are known but assignee is not, with load balancing. Excludes `post_task` for intentional assignees and `broadcast` for non-tracked notifications. Also documents the v2.1 `allow_self_assign` opt-in behavior.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Maxlumiere/bot-relay-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server