Skip to main content
Glama

Heista

by co.heista

Dispatch — Head of Research

dispatch_head_of_research

Run a full research workflow via the Head of Research agent. The Head decomposes your brief into specialist sub-questions, dispatches the right combination of 6 specialists (desk, trend, market, quant, qual, social) in parallel via async dispatch, polls them to completion, judges output quality, and returns a structured synthesis. Use for: any source-grounded research request — fact-checking, vendor teardowns, trend assessment, quantitative effect-size analysis, qualitative theme extraction, cross-platform discourse mapping, or any combination. Wall time: 2-5 min typical. Returns: { synthesis, head_session_id, status, event_count, tool_uses, elapsed_ms }. NOT for: non-research requests (writing, coding, casual chat) — respond directly without calling this. Cost: $0.20-1.50 per call depending on brief complexity (specialist token spend + Anthropic session-runtime at $0.08/hr).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefYesThe research brief to send to the Head. Must be self-contained — the Head sees only this string, no conversation history. Include entity, time window, scope, and unit of analysis explicitly. Be concrete: vague briefs produce vague output.
priorityNostandard (default) uses production models in specialists; deep escalates to higher-capability models. Use deep when accuracy matters more than cost.
max_wait_secondsNoHard cap on how long to wait for the Head session to complete. Default 270 (4.5 min). Heads typically complete in 2-5 min; raise this if you expect a deep research brief.

TDQS

A5/5.0
Behavior5/5

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

Describes the full workflow: decomposition, parallel dispatch, polling, quality judgment, and synthesis. Includes wall time (2-5 min), cost ($0.20-1.50), and return fields. No contradictions with annotations; adds significant context beyond readOnlyHint and openWorldHint.

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 a well-structured paragraph that front-loads the main action, then flows logically through workflow, usage, exclusions, cost, and returns. Every sentence adds necessary information; no waste.

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?

Given no output schema, the description provides the return format. With 3 parameters all described, annotations present, and complexity high (orchestrating 6 specialists), the description covers workflow, timing, cost, and constraints completely.

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?

With 100% schema coverage, the description still adds value: brief parameter gets guidance on self-contained structure and concreteness; priority explains production vs. deep models and cost implications; max_wait_seconds explains default and when to adjust. These exceed 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 it runs a full research workflow via the Head of Research agent, decomposing briefs into specialist sub-questions and orchestrating parallel dispatch. It distinguishes itself from individual specialist dispatchers (e.g., dispatch_desk_researcher) by being the orchestrator, and lists concrete use cases.

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?

Explicitly states when to use (source-grounded research requests) and when not (non-research requests like writing or casual chat). Also provides wall time, cost range, and return structure, helping agents decide appropriateness.

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

All Heista toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation4/5

Despite the high tool count, most tools have distinct purposes with thorough descriptions that specify when to use each. Some overlap exists among creative direction tools (call_creative_worlds vs chat_with_creative_worlds), but the descriptions clarify usage patterns.

Naming Consistency3/5

Naming conventions are inconsistent overall: some follow verb_noun (create_powersource_url, decode_ad), others use noun_verb or compound names (adformula_intelligence, fleet_analytics_overview). However, subgroups like dispatch_* and list_*_presets maintain internal consistency.

Tool Count2/5

112 tools is far beyond the typical 3-15 range for well-scoped servers. While the server covers a broad domain, the sheer number likely overwhelms agents and suggests insufficient consolidation of related operations.

Completeness4/5

The tool set covers core creative intelligence workflows: brand analysis, ad decoding, script generation, creative direction, and research. Minor gaps exist (e.g., no social media publishing tools), but the main use cases are well-supported.

Resources