Skip to main content
Glama
Sign In
med-lit-mcp

med-lit-mcp

by junhewk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

set_screening_criteria

DestructiveIdempotent

Save inclusion and exclusion criteria and their reasons for medical literature screening, creating an auditable basis for consistent screening decisions.

Instructions

Save the researcher's inclusion and exclusion criteria (and the reason for each) for screening. Rules: guide("screening").

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>",
      "include": "<include>",
      "exclude": "<exclude>"
    },
    "name": "set_screening_criteria"
  }
}

Input Schema

NameRequiredDescriptionDefault
run_idYesRun ID from start_search
excludeYesExclusion criteria in the researcher's words
includeYesInclusion criteria in the researcher's words
reasonsNoWhy each criterion follows from the question, keyed I1, I2 … (inclusion) and E1, E2 … (exclusion) in order; required in a research mode
replaceNoRequired to change existing criteria; starts a new revision and re-screens everything

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / reasons
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Why each criterion follows from the question, keyed I1, I2 … (inclusion) and E1, E2 … (exclusion) in order; required in a research mode",
+  "title": "Reasons"
+}
  2. First observedv0.1.1

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description could have added the key behavioral fact — that changing existing criteria requires replace and re-screens everything — but leaves it entirely to the schema. The 'Rules: guide("screening")' line hints that external rules govern validity but doesn't say what they are or what happens on violation. Adequate but thin given the destructive profile.

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 short sentences with the core action front-loaded and no filler. The 'Rules: guide("screening")' fragment is tersely opaque — it reads as an internal pointer rather than usable guidance — which slightly undercuts an otherwise efficient definition.

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, and the parameters are fully described in the schema. What's missing is the sequencing context an agent needs: when in the pipeline to call this, and that revising criteria is a destructive revision-and-rescreen operation. Adequate but not complete for a destructive, pipeline-critical mutation.

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 five parameters, including replace, reasons, and run_id, are already documented in structured fields; the baseline is 3. The description's parenthetical '(and the reason for each)' loosely reinforces the reasons parameter but adds no new syntax, keying convention, or ordering detail beyond the schema.

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+resource: save the researcher's inclusion and exclusion criteria plus per-criterion reasons for screening. This is clearly distinct from the sibling record_screening_decisions, which records outcomes rather than criteria. The trailing cryptic 'Rules: guide("screening")' adds no clarity but doesn't obscure the purpose.

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 'for screening' phrase implies this is a pre-screening setup step, and the guide("screening") pointer hints at where rules live. However, there is no explicit when-to-use, no statement of prerequisites (e.g., after start_search, before next_screening_batch), and no differentiation from record_screening_decisions or add_skipped_articles.

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