Skip to main content
Glama

Check cheaply whether delegating is worth it

routing_preflight

Evaluate delegation feasibility before exploring code. Provide ownership seams and sharing constraints to receive a route (solo, either, or delegation-plausible) with the key signals.

Instructions

Cheap deterministic check of whether delegating is structurally sound and economically sensible, before any repository exploration. Declare the ownership seams you are considering and what they share; leave a field "unknown" when you do not know, which biases the advice toward solo without ever refusing. Creates no worker, batch, worktree, or thread, refuses nothing, and returns route (solo | either | delegation-plausible), the deciding signals, and structural parallel eligibility. Advisory only and never required: the parent owns sequential vs parallel, worker count, effort, and the final decision, and choosing zero workers afterwards is a normal successful outcome. either means fixed delegation overhead needs explicit justification, otherwise stay solo.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seamsYes
seamSizeNounknown
coreOverlapNounknown
integrationNounknown
sharedStateNounknown
verificationNounknown
Install Server

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries full burden. It explicitly states 'Creates no worker, batch, worktree, or thread, refuses nothing' – clearly disclosing side-effect-free behavior. It describes the return values (route, deciding signals, structural parallel eligibility) and explains how unknown inputs bias results toward solo. The advisory and non-required nature is also disclosed, giving the agent complete understanding of behavioral traits.

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 the core purpose in the first sentence. It then flows naturally from usage timing to input guidance to output and interpretation. It is three sentences but dense, with each clause earning its place. Slightly verbose with multiple embedded clauses, but still well-structured and avoids fluff.

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 having 6 parameters and no output schema, the description covers all essential aspects: what the tool does, when to use it, its side-effect-free nature, the input guidance (include seams, mark unknowns), the output format (route, deciding signals, eligibility), and how to interpret results (either requires justification). An agent has enough information to call it correctly without further lookup.

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 description coverage is 0%, so the description must compensate. It provides a high-level hint: 'Declare the ownership seams you are considering and what they share' – this loosely maps to seams and sharedState/coreOverlap. It also advises leaving fields 'unknown' when unsure. However, it does not explain the semantic meaning of seamSize, integration, or verification individually, leaving some parameters under-documented. The description adds some value but does not fully compensate for the schema gap.

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 opens with 'Cheap deterministic check of whether delegating is structurally sound and economically sensible, before any repository exploration.' This is a specific verb (check) and resource (delegating) with a clear scope and timing. It distinguishes itself from siblings like delegate_task by explicitly stating it creates no worker/batch/worktree/thread, making it clear it is a preflight rather than an execution tool.

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 states it is used 'before any repository exploration' and is 'advisory only and never required', clarifying it is a precursor to actual delegation. It also explains when the output suggests staying solo vs. delegating ('either means fixed delegation overhead needs explicit justification, otherwise stay solo'). However, it does not explicitly name sibling tools or state 'use delegate_task instead when you are ready to execute', so the contrast with alternatives is implied rather than explicit.

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

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/mahadansar/sol-luna-orchestrator'

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