Skip to main content
Glama

parse_document

Parses a study report into section spans with character offsets and an evidence cue survey, enabling ROBINS-I bias assessment. Accepts text or server-readable path; supplements optional.

Instructions

PRIMARY entry point: parse a study report into a bundle with character-offset, source-tagged section spans. Every quote you later cite is resolved against THIS text, and every claim of absence is searched in it.

PASS citation=: the full bibliographic reference in APA style. It appears on the rendered assessment so the study being judged is unambiguous.

document is EITHER the raw text OR a file path — but the path must be readable on the SERVER host. If your files live on your own filesystem, paste the TEXT instead, or use parse_pmcid for an open-access PMCID. A path-looking string the server cannot find raises rather than being ingested as its own text.

PASS THE SUPPLEMENT WHEN YOU HAVE IT. supplements is a list of server-readable paths merged as supplementary material. This matters more for ROBINS-I than for a reporting audit: the target-trial specification that settles C1-C4, and the analysis detail domains 1 and 4 turn on, routinely live only in the appendix. Without it those questions read NI when the answer was merely in a file nobody passed. supplement_status defaults to 'user_provided' when supplements are given; pass 'none_exists' to assert the article has none.

Returns the section map, the text hash that keys later calls, and a cue survey — hit counts for the 15 evidence patterns, so you can see before reading where each domain's evidence lives and which absences already look real.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
citationNo
documentYes
supplementsNo
manuscript_idNo
supplement_statusNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceNo
n_pagesNo
citationNo
sectionsNo
warningsNo
documentsNo
full_textNo
next_stepNo
cue_surveyNo
text_sha256No
manuscript_idNo
extractor_versionNo
supplement_statusNo
Behavior5/5

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

Without annotations, the description discloses error behavior (server-unreadable paths raise), defaults (supplement_status), and the foundational property that all later citations resolve against this parse. It also explains the return value's structure (section map, text hash, cue survey).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although lengthy, every paragraph is dense with necessary operational details (alternatives, defaults, error handling). The critical 'PRIMARY entry point' is front-loaded, and there is no redundant or filler text.

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

Completeness5/5

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

The description covers the tool's role, parameter handling, error conditions, return values, and relationship to later calls. Given the output schema exists and the tool is complex, this is fully complete.

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?

The description adds detailed semantics for citation, document, supplements, and supplement_status, which are absent from the schema. However, manuscript_id is not mentioned at all, creating a gap in understanding for that parameter.

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?

The description opens with 'PRIMARY entry point' and a specific verb-object: 'parse a study report into a bundle with character-offset, source-tagged section spans.' It explicitly contrasts with parse_pmcid, distinguishing the tool's scope.

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

Usage Guidelines5/5

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

Provides explicit guidance: pass citation for APA reference, use text directly if files are local, use parse_pmcid for open-access, pass supplements when available, and set supplement_status to 'none_exists' when appropriate. This clearly indicates when to use this tool vs siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Black-Swan-Causal-Labs/robins-i-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server