Skip to main content
Glama
Galbaz1

video-research-mcp

by Galbaz1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Research Web Followup

research_web_followup

Ask follow-up questions about a completed Deep Research report using the previous interaction ID to maintain context for fast, synchronous responses.

Instructions

Ask a follow-up question about a completed Deep Research report.

Uses previous_interaction_id to maintain context from the original research. Synchronous — follow-ups are fast (no background needed).

Input Schema

NameRequiredDescriptionDefault
job_idNoResume a recorded follow-up without repeating inference
questionYesFollow-up question about the research report
interaction_idYesCompleted interaction ID to follow up on

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.1
    • addedInput schema / properties / job_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Resume a recorded follow-up without repeating inference"
+}
  2. First observedv0.6.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=true, and the description usefully adds that this is synchronous and fast with no background job needed, plus that it reuses prior context. It does not explain why the call is not read-only (new inference is generated) nor mention cost or limits, but it contributes real context beyond the annotations.

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?

Three short sentences, front-loaded with the purpose, then context retention, then the synchronous trait — no padding. The mismatched parameter name ('previous_interaction_id') slightly undercuts an otherwise tight structure.

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?

With an output schema present, return values need no explanation, and the annotations cover the safety profile. The description supplies purpose, prerequisite, and synchronous behavior, though the parameter-name mismatch and unaddressed job_id path leave small gaps for an agent orchestrating a research workflow.

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 100%, so all three parameters are documented in the schema, giving a baseline of 3. The description adds context-retention meaning for the interaction id, but it refers to it as 'previous_interaction_id', which does not match the schema's 'interaction_id', and it never mentions the optional job_id resume parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('ask a follow-up question about a completed Deep Research report') and ties it to the Deep Research workflow, which is enough to separate it from research_web and research_web_status. It stops short of naming the sibling tool whose output it consumes, so differentiation relies on inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'about a completed Deep Research report' implies the prerequisite (a finished research interaction) and the context in which to use it. There is no explicit when-not or alternative routing, e.g. what to do if the report is still running, leaving usage to inference.

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

Deploy Server

Other Tools