med-lit-mcp

Overview Schema Source Related Servers Discussions Admin

record_screening_decisions

Destructive

Capture literature screening judgments (include, exclude, uncertain) with verbatim evidence quotes required for include/exclude, producing auditable, source-linked review records.

Instructions

Record screening decisions; include/exclude need a verbatim quote as evidence.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "run_id": "<run_id>",
      "revision": "<revision>",
      "decisions": "<decisions>"
    },
    "name": "record_screening_decisions"
  }
}

Input Schema

Name	Required	Description
`run_id`	Yes	Run ID from start_search
`revision`	Yes	revision from next_screening_batch
`decisions`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.3.0Oct 29, 2026

removedInput schema / $defs

Removed value: -{
-  "ScreeningDecision": {
-    "additionalProperties": false,
-    "properties": {
-      "decision": {
-        "enum": [
-          "include",
-          "exclude",
-          "uncertain"
-        ],
-        "title": "Decision",
-        "type": "string"
-      },
-      "evidence": {
-        "default": "",
-        "description": "Verbatim quote; required for include/exclude",
-        "maxLength": 500,
-        "title": "Evidence",
-        "type": "string"
-      },
-      "reason": {
-        "maxLength": 1000,
-        "minLength": 1,
-        "title": "Reason",
-        "type": "string"
-      },
-      "uid": {
-        "title": "Uid",
-        "type": "string"
-      }
-    },
-    "required": [
-      "uid",
-      "decision",
-      "reason"
-    ],
-    "title": "ScreeningDecision",
-    "type": "object"
-  }
-}

removedInput schema / properties / decisions / items / $ref
```
Removed value: -"#/$defs/ScreeningDecision"
```
addedInput schema / properties / decisions / items / additionalProperties
```
Added value: +false
```

addedInput schema / properties / decisions / items / properties

Added value: +{
+  "criterion": {
+    "default": "",
+    "description": "Code of the criterion an exclude rests on: E1 (meets exclusion 1) or I2 (fails inclusion 2)",
+    "maxLength": 4,
+    "title": "Criterion",
+    "type": "string"
+  },
+  "decision": {
+    "enum": [
+      "include",
+      "exclude",
+      "uncertain"
+    ],
+    "title": "Decision",
+    "type": "string"
+  },
+  "evidence": {
+    "default": "",
+    "description": "Verbatim quote; required for include/exclude",
+    "maxLength": 500,
+    "title": "Evidence",
+    "type": "string"
+  },
+  "reason": {
+    "maxLength": 1000,
+    "minLength": 1,
+    "title": "Reason",
+    "type": "string"
+  },
+  "uid": {
+    "title": "Uid",
+    "type": "string"
+  }
+}

addedInput schema / properties / decisions / items / required
```
Added value: +[
+  "uid",
+  "decision",
+  "reason"
+]
```
addedInput schema / properties / decisions / items / title
```
Added value: +"ScreeningDecision"
```
addedInput schema / properties / decisions / items / type
```
Added value: +"object"
```

First observedv0.1.1Sep 29, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this is an irreversible write. The description adds one useful behavioral rule — include/exclude decisions need a verbatim quote — but says nothing about what happens to the run on submission, whether resubmission with a stale revision fails, or the 25-decision cap.

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?

A single compact sentence with the most load-bearing rule (evidence quotes) front-loaded. It is efficient, though the compression borders on under-specification for a multi-parameter write tool.

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 values need not be explained, but this is a destructive, revision-guarded batch write with a nested decisions array and the description covers only the evidence rule. Missing are batch/submission semantics and revision-staleness behavior, leaving the agent to infer the workflow from parameter descriptions.

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 67% and the schema already documents run_id, revision, and the evidence/criterion fields including 'required for include/exclude'. The description's quote requirement largely restates the evidence field description, and it adds no meaning for the 25-item batch limit or revision semantics.

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 names a specific verb (record) and resource (screening decisions), which clearly separates it from siblings like record_triage_scores, record_extraction, or record_synthesis. It does not explicitly differentiate from the closest workflow siblings (next_screening_batch), but the resource name is unambiguous.

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

Usage Guidelines2/5

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

There is no statement of when to call this versus alternatives, nor any mention that it must follow next_screening_batch or that revision must come from that batch — that context only appears buried in the schema parameter descriptions. The agent gets no routing or precondition guidance from the description itself.

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