Skip to main content
Glama
Literature Evidence MCP

Literature Evidence MCP

by Furox-Art

prisma_dual_screen

Two independent reviewer screening decisions and one-stage PRISMA flow counts.

Instructions

Two independent reviewer screening decisions and one-stage PRISMA flow counts.

Input Schema

NameRequiredDescriptionDefault
recordsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

D1.6/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It vaguely implies a write/record operation (screening decisions and flow counts) but does not state whether it mutates state, what permissions are needed, how duplicate/reviewer-conflict handling works, or what is returned. The mention of 'two independent reviewer' decisions is the only substantive hint.

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?

It is short but this is under-specification, not conciseness. There is no front-loaded action statement, and the fragment does not earn its place as a usable instruction.

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

Completeness1/5

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

For a tool with an unconstrained nested-object array parameter, no annotations, and no output schema, the description supplies none of the missing context. An agent cannot reliably invoke it.

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

Parameters1/5

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

The sole parameter 'records' is an array of untyped objects with additionalProperties=true and 0% schema description coverage. The description never documents the expected record shape (reviewer id, decision value, exclusion reason, etc.), leaving the agent unable to construct valid input.

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

Purpose2/5

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

The text is a noun phrase listing two outputs ('screening decisions', 'PRISMA flow counts') rather than a verb+resource statement of what the tool does. It also gives no basis to distinguish it from the sibling prisma_review_flow, which shares the same PRISMA domain.

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

Usage Guidelines1/5

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

There is no indication of when to call this versus prisma_review_flow or prisma_review_flow's related siblings, nor any stated precondition (e.g., duplicate reviewers required for 'dual' screening). The agent must guess the usage context entirely.

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