Skip to main content
Glama
NLY22
by NLY22

ps_research_start

Start a long-session research task that breaks a question into sub-questions, investigates each against your corpus, and returns a cited markdown report. State persists for follow-up after restarts.

Instructions

Open a long-session research task: decompose the question, investigate each sub-question against the corpus, return a cited markdown report. State persists — follow up later, even after restarts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
questionYes
config_pathNo
periscope_pathNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It usefully discloses that this is a long-session task with persistent state and a markdown report return, which matters for an agent. However, it says nothing about cost, latency, permissions, or whether the task is asynchronous vs blocking — significant gaps for a long-running operation.

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?

Two tight sentences, front-loaded with the core action and the pipeline it triggers. No filler; the persistence note earns its place. Slightly dense but well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return format needn't be explained, and the description does cover the task lifecycle. But with zero annotation coverage, 0% parameter documentation, and no mention of the two config-path arguments, an agent lacks enough to invoke this long-running tool confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for 3 parameters. The description never mentions config_path or periscope_path, leaving two parameters entirely undocumented in both schema and prose. "question" is inferable from the workflow narrative, but the two config paths are opaque.

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 ("Open a long-session research task") and enumerates the internal workflow (decompose, investigate sub-questions, return a cited markdown report). It is distinguishable from read-only siblings like ps_research_status or ps_research_list, though it never names an alternative to sharpen the contrast.

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 "follow up later, even after restarts" implies this is the entry point that pairs with ps_research_followup, but no explicit when-to-use or when-not-to-use guidance is given. Usage is inferable but not stated.

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