Phở Research Tools

PRISMA 2020 flow diagram

prisma_flow_diagram

Read-onlyIdempotent

Draw a PRISMA 2020 flow diagram for a new systematic review from the record counts, as a PNG image plus an SVG and download links. Give the counts you have; screened, sought, assessed and reports-included boxes that follow from others are filled in and marked as derived. Studies included is never derived. The tool checks that the numbers add up (records identified minus removed equals screened, and so on) and returns a warning naming each box that does not, with the value it should have. The diagram always shows the numbers exactly as given. Add otherMethods counts to draw the second column (websites, organisations, citation searching).

Input Schema

Name	Required	Description
`counts`	Yes
`footnotes`	No	Print the template footnotes and source attribution.
`other_methods_column`	No	Force the other-methods column on or off. Default: drawn when otherMethods counts are given.

Output Schema

Name	Required	Description	Default
`svg`	Yes
`width`	Yes
`counts`	Yes
`height`	Yes
`svg_url`	No
`warnings`	Yes
`image_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedOct 19, 2026

changedInput schema / properties / counts / properties / databaseSources / description

Previous value: -"Per-database counts, e.g. [{\"name\":\"MEDLINE\",\"n\":812}]."New value: +"Per-database counts before deduplication, e.g. [{\"name\":\"MEDLINE\",\"n\":812}]. If databases is also given, the two are compared."

changedInput schema / properties / counts / properties / databases / description

Previous value: -"Records identified from databases (total)."New value: +"Records identified from databases, all databases together, before duplicates are removed. Leave out when databaseSources is given: it is their sum."

addedInput schema / properties / counts / properties / duplicatesRemoved / description
```
Added value: +"Duplicate records removed before screening."
```

addedInput schema / properties / counts / properties / recordsExcluded / description

Added value: +"Records excluded at title and abstract screening (not reports excluded at full text)."

addedInput schema / properties / counts / properties / recordsScreened / description

Added value: +"Records screened on title and abstract. Derived when left out: identified minus removed before screening."

changedInput schema / properties / counts / properties / registers / description

Previous value: -"Records identified from registers."New value: +"Records identified from trial registers (ClinicalTrials.gov, ICTRP…), before duplicates are removed."

changedInput schema / properties / counts / properties / reportsAssessed / description

Previous value: -"Reports assessed for eligibility."New value: +"Full-text reports assessed for eligibility. Derived when left out: sought minus not retrieved."

changedInput schema / properties / counts / properties / reportsExcluded / description

Previous value: -"Total reports excluded, when reasons are not itemised."New value: +"Total full-text reports excluded. If reasons are also given, their sum is compared with it."

changedInput schema / properties / counts / properties / reportsExcludedReasons / description

Previous value: -"Reports excluded, one entry per reason."New value: +"Full-text reports excluded, one entry per reason, e.g. [{\"name\":\"Wrong population\",\"n\":12}]."

changedInput schema / properties / counts / properties / reportsIncluded / description

Previous value: -"Reports of included studies."New value: +"Reports of included studies. Derived when left out: assessed minus excluded (both columns when otherMethods is drawn)."

addedInput schema / properties / counts / properties / reportsNotRetrieved / description
```
Added value: +"Reports that could not be retrieved."
```

changedInput schema / properties / counts / properties / reportsSought / description

Previous value: -"Reports sought for retrieval."New value: +"Full-text reports sought for retrieval. Derived when left out: screened minus excluded."

changedInput schema / properties / counts / properties / studiesIncluded / description

Previous value: -"Studies included in the review."New value: +"Studies included in the review. Never derived: one study can have several reports, so give it. It cannot exceed reportsIncluded."

First observedOct 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the read-only/idempotent annotations: it discloses the arithmetic validation ('checks that the numbers add up'), that it returns a warning naming each inconsistent box with the expected value, that derived boxes are marked as derived, that studiesIncluded is never derived, and that the diagram renders numbers exactly as given. This is substantive behavioral detail an agent needs.

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?

Dense but front-loaded: the core action and outputs open the text, followed by derivation and validation rules. Every sentence carries information, though the paragraph could be split for easier scanning.

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?

Given the deeply nested counts object and an existing output schema, the description covers the essential derivation, validation, and column behaviors an agent needs. Return-value explanation is rightly omitted because an output schema exists, though it does not mention limits such as the 30-source caps or deduplication comparison between databases and databaseSources.

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 coverage is 67% and the description adds genuine semantic value: it explains the derivation rule for screened/sought/assessed/reportsIncluded, clarifies that otherMethods counts draw the second column, and stresses that studiesIncluded must be supplied. It does not touch footnotes or the explicit column toggle, leaving some schema-covered ground only in the schema.

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

Purpose5/5

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

States a specific verb and resource: 'Draw a PRISMA 2020 flow diagram ... from the record counts,' and names the concrete outputs (PNG plus SVG and download links). The purpose is unmistakable and none of the sibling tools overlap with it.

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?

Gives clear context for invocation ('Give the counts you have') and explains which boxes are auto-derived versus which the user must supply, which guides input decisions. It does not name explicit when-not-to-use conditions or alternatives, but no sibling offers a comparable capability, so the gap is minor.

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

All Phở Research Tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.