Research Toolkit

Overview Schema Source Related Servers Discussions Admin

research_review

Prepare and dispatch independent review assignments for research reports, then collect host-completed results and manage revisions through audit and final acceptance.

Instructions

Prepare independent assignments or receive the host's actual completed result; no API setup is needed. The host dispatches distinct non-author agents: seven whole-report perspectives and domain review, then an independent audit with independently selected samples, then independent final acceptance. host_result uses slot_id, host_task (actual session handle), response_path and execution_path (task-relative original UTF-8 response and completed host capture). Original responses quote input_version and assignment_version. execution_path records host_task, status=completed and assignment_version. Do not fabricate responses or identities. evidence_paths may be empty when registered original evidence suffices; required sources are included automatically. Each pending assignment includes reading_ref: open its readable input and full-text links when dispatching the host agent. On revision, resume_host_task identifies the earlier independent context to continue when available; revision_context compares the current input with that role's actual reviewed version and retains its original work. Omitted perspectives/domains continue the saved unit selection; explicit values change the selection. assignment_ref remains the original frozen JSON; include_assignment=False avoids repeating it inline. Versions are unchanged. For progressive work set scope to a saved unit_id and artifact to its draft; perspectives selects relevant unit reviews. New units default to no domain review; domains supplies needed specialist perspectives. audit=True adds independent unit adjudication when needed, retaining existing content results. An enabled audit cannot be removed; full reports always require audit and final acceptance. Main drafts must have their actual producer registered via save draft.host_task. Revision assignments reference earlier reviews, frozen inputs and changed locations; these are reading aids, not current PASS. A completed negative review is retained. Correct the draft, then use revision=True; do not reroll for a pass. reviewer=self and self_review remain recognizable legacy parameters but cannot complete current independent review. Explicitly configured external backends execute the same assignments; ordinary use stays in the host.

Input Schema

Name	Required	Default
`task`	Yes
`audit`	No
`scope`	No	full_report
`domains`	No
`purpose`	No	report_delivery
`artifact`	No	final.md
`reviewer`	No
`revision`	No
`host_result`	No
`self_review`	No
`perspectives`	No
`evidence_paths`	Yes
`include_assignment`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv2.0.1Oct 31, 2026

addedInput schema / properties / audit

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Audit"
+}

addedInput schema / properties / domains

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

addedInput schema / properties / host_result

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

changedInput schema / properties / include_assignment / default
```
Previous value: -trueNew value: +false
```

addedInput schema / properties / perspectives

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

addedInput schema / properties / scope

Added value: +{
+  "default": "full_report",
+  "title": "Scope",
+  "type": "string"
+}

First observedv1.1.0Oct 15, 2026

TDQS

A3.9/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 add substantial behavioral context: no API setup needed, host dispatches distinct non-author agents, an enabled audit cannot be removed, main drafts must have a registered producer, negative reviews are retained, and reviewer=self is a legacy path that cannot complete current review. Gaps remain around return/error behavior, but the operational profile is unusually detailed.

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 content is dense and largely earns its place, but it arrives as an unstructured block with no front-loaded summary and several cryptic sentences (e.g., 'these are reading aids, not current PASS'). Size is defensible given complexity, but readability and ordering suffer.

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?

For a 13-parameter, annotation-free orchestration tool with an output schema, the description covers the dispatch/audit/revision/reviewer behavior and most parameters adequately. The main omissions are the meaning of 'task' and 'purpose', though return values are covered by the output schema.

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 0%, so the description must compensate and largely does, explaining host_result fields, assignment_ref, include_assignment, scope, artifact, perspectives, domains, audit, revision, reviewer, self_review, and evidence_paths. The required 'task' and 'purpose' parameters are never explained, and the mappings are scattered rather than systematic.

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?

The description identifies the resource and pipeline clearly: it prepares independent review assignments (seven whole-report perspectives, domain review, independent audit, final acceptance) or receives the host's completed result. The dual verb ('prepare ... or receive') muddies the one-line purpose, but the subject matter is specific and distinct from siblings like research_check_reviewer or research_finish.

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

Usage Guidelines4/5

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

Strong conditional guidance is present: when to use revision=True (after correcting a draft, not to reroll for a pass), when audit becomes required, and how omitted vs explicit perspectives/domains change selection. It stops short of explicitly contrasting this tool against siblings, leaving some inference required.

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

Deploy Server