Skip to main content
Glama

research_pipeline

Structure and preserve research findings through a six-phase workflow: create outline, gather content, review quality, analyze data, verify claims, and finalize reports.

Instructions

[PIPELINE] RECOMMENDED for research tasks. Orchestrates all underlying Context-First layers through 6 phases (init→gather→review→analyze→verify→finalize). NEW: plan→draft→review→fix loop — like compile→test→fix in coding. Init generates a research outline (12+ sections). Each gather adds depth to one section with quality gate (25K char / 500 line min — multiple gathers per section expected). Review runs quality tests and identifies gaps. CRITICAL: Interleave web search and gather — after EACH search, IMMEDIATELY call gather with deeply written content. Do NOT batch searches. Each gather writes a file to disk. After sufficient gathers, call review to run quality tests. Fix failed sections by gathering again with metadata.targetSection=N. Coverage must reach 60% before analyze. Autonomous file writing is ALWAYS ON — files are written to disk during gather, analyze, and finalize phases. Provide outputDir to control destination, or let the pipeline auto-create a temp directory. Finalize works even if verify hasn't passed. It does not browse the web or invent source material for you; use it to structure, preserve, pressure-test, and export sourced findings collected from web, GitHub, fetch, or other MCP tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sessionIdNodefault
phaseYesPipeline phase. Call in order: init → gather (repeatable) → review → analyze → verify → finalize. Each phase auto-chains the appropriate layer tools internally. Analyze is blocked until gathered evidence clears the weak-evidence gate and coverage ≥ 60%.
contentYesPhase-specific content: init=task description, gather=WRITE a deeply researched section based on your LATEST web search. CRITICAL WORKFLOW: Do ONE web search, then IMMEDIATELY call gather. Repeat. Do NOT do multiple searches before calling gather — content gets lost to compaction. You are a research AUTHOR: use the search result as input to write a comprehensive section with specific facts, data, analysis, relationships, and expert commentary. Each gather call writes one file to disk immediately — this is the pipeline's core output. analyze=problem/question to reason about (runs on accumulated gather files), verify=draft output to verify (runs on accumulated files), finalize=final summary to persist (synthesizes all files)
outputDirNoRECOMMENDED. When provided, the pipeline autonomously writes enriched research files to this directory during gather, analyze, and finalize phases. This eliminates the need for the LLM to write files manually — the pipeline writes them itself, like how export_research_files works but incrementally per-phase. Files survive context compaction because they are on disk, not just in memory. Prefer an absolute path.
baseFileNameNoBase filename prefix for autonomously written files when outputDir is set. Produces files like research.batch-001.topic-slug.md, research.analysis-001.md, research.synthesis.mdresearch
messagesNoRecent conversation messages for context_loop
claimNoSpecific claim to fact-check (verify phase)
metadataNoOptional metadata for memory storage and finalize/export controls. Supported conventions: sourceTools during gather, maxChunkChars during finalize, exportChunkIndex during finalize chunk retrieval, outline (Array<{title, description}>) during gather to set the research outline, targetSection (number) during gather to expand/append depth to a specific outline section (multi-gather accumulation).
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: autonomous file writing to disk during phases, quality gates (25K char/500 line min, 60% coverage requirement), phase dependencies (analyze blocked until coverage threshold), and critical workflow constraints (immediate gather after search). It explains operational mechanics like file persistence and phase chaining.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and workflow but becomes verbose with repetitive instructions (e.g., multiple warnings about immediate gather). Some sentences could be condensed (e.g., overlapping explanations of file writing). It's informative but not optimally concise, with minor redundancy.

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 the tool's complexity (8 parameters, no annotations, no output schema), the description is highly complete: it explains the multi-phase process, behavioral constraints, file management, and integration with other tools. It compensates for lack of structured fields by detailing usage, dependencies, and outputs sufficiently for an agent to operate it correctly.

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 description coverage is high (88%), so baseline is 3. The description adds value by clarifying parameter usage in context: e.g., content's role per phase (init=task description, gather=write based on latest search), outputDir's purpose for autonomous file writing, and metadata conventions like targetSection for multi-gather accumulation. However, it doesn't fully detail all 8 parameters beyond schema hints.

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 orchestrates research tasks through 6 phases (init→gather→review→analyze→verify→finalize), specifying it structures, preserves, pressure-tests, and exports sourced findings. It distinguishes from siblings by focusing on research orchestration rather than isolated functions like export_research_files or memory.

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 guidance is provided: 'RECOMMENDED for research tasks,' with detailed workflow instructions (e.g., interleave web search and gather, do not batch searches, call phases in order). It contrasts with alternatives by noting it does not browse the web or invent source material, implying use of other MCP tools for sourcing.

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/XJTLUmedia/Context-First-MCP'

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