Research Toolkit

Overview Schema Source Related Servers Discussions Admin

research_status

Read research progress and stage status, optionally advance stages when prerequisites exist, and prepare context for collecting, analyzing, drafting, or revising work.

Instructions

Read progress and stage methods. Optional stage advances to collect/analyze/draft/revise only after prerequisite records exist. When work selects a branch, check its sources/claims and declared upstream inputs; unrelated pending branches do not block it. Whole-report review and final completion retain complete task checks. language accepts "en" (English), "zh" or "zh-CN" (the same Chinese methods); checked before any stage change. Explicit analyze/draft entry includes saved requirements as JSONL text when present, preserving statuses and evidence. changes reuses the latest successful record-save batch and locates related claims in the latest registered draft. Literal matches guide reading, not semantic verdicts; not_located requires inspection, not a new acceptance gate. current_work locates the main artifact, requirements and historical receipt separately. runtime identifies this implementation, not the Skill actually read by the host. Status does not discover arbitrary unregistered files. current_work includes effective_requirements (including satisfied), scope_decisions and research_outputs. Optional methods selects named methods from research_guide.available_methods instead of the stage defaults. Optional work prepares readable input for research, delegation or revision: question, unit_id, depends_on, requirement_ids, claim_ids, source_ids and paths (all optional). unit_id resumes saved work; depends_on selects upstream units for a new assignment. Their full artifacts and bound originals are included, not just handoff summaries. Selected claims include supporting and counter-evidence sources. Dependency results distinguish incomplete work, changed inputs/versions and pending independent review. Fulfilled requirements remain effective unless superseded. work_context includes originals, effective requirements, references and inputs hashes (files plus selected record bindings). reading_ref opens a readable view of that same work input, with full text in linked files instead of escaped JSON strings. Pass this entry and task_directory to the host worker; work_context and its input hashes remain unchanged. Preparing a unit records its selection in existing activity history for the next save; ordinary status remains read-only. current_work.production_contexts retains recorded production identities for independent assignments. Choose scope yourself; send the input through the host's existing agent tools, preserving its actual task handle for follow-up. No host agent is launched by this read. Omit stage to prepare independent work without changing global progress.

Input Schema

Name	Required	Default
`task`	Yes
`work`	No
`stage`	No
`methods`	No
`language`	No	en

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.5.0Oct 29, 2026

addedInput schema / properties / methods

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Methods"
+}

addedInput schema / properties / work

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Work"
+}

First observedv1.1.0Oct 15, 2026

TDQS

B3.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it states 'ordinary status remains read-only', 'No host agent is launched by this read', that stage changes are gated on prerequisite records, and that language is validated before any stage change. These are substantive behavioral facts an agent could not get elsewhere, though the delivery is buried in jargon.

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

Conciseness2/5

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

Roughly 300 dense words of run-on, jargon-heavy sentences that hop between topics (status reads, stage gating, work preparation, host delegation, file discovery) with no headings or front-loading. Key operational facts are buried mid-paragraph, and many clauses could be trimmed or reordered for scanability.

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-value explanation is not required, and the description covers the read-only nature and stage-change prerequisites. But for a 5-parameter tool with 0% schema coverage, the unexplained required 'task' parameter and the tangled work/delegation semantics leave the agent under-equipped to invoke it confidently.

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 0%, so the description must compensate, and it does describe stage values (collect/analyze/draft/revise), language codes ('en', 'zh'/'zh-CN'), methods (selecting from research_guide.available_methods), and work's subfields (question, unit_id, depends_on, requirement_ids, claim_ids, source_ids, paths). The required 'task' parameter is never explained at all, leaving a notable gap for the one mandatory argument.

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

Purpose3/5

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

The opening 'Read progress and stage methods' states a specific verb+resource, but the description then extends into advancing stages, preparing work input, and opening reading views without ever reconciling these apparently different functions into a single purpose statement. An agent can grasp it's a status/read entry point but must reconstruct the overall job from scattered clauses.

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?

There is real conditional guidance ('Omit stage to prepare independent work without changing global progress', 'stage advances ... only after prerequisite records exist'), which implies when to use it. However, no sibling is named or contrasted (research_guide, research_save, research_review all overlap conceptually), so the agent must infer routing itself.

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

Deploy Server