Skip to main content
Glama

parse_manuscript

Parse a manuscript into source-tagged section spans, detect protocol tables/flow diagrams, and return a text hash. Include supplements so appendix content is assessed rather than marked not reported.

Instructions

PRIMARY entry point: parse a manuscript into a SectionMap with character-offset, source-tagged section spans.

PASS citation=: the manuscript's full bibliographic reference in APA style (authors, year, title, journal, volume(issue), pages, DOI). It is carried into the assessment and displayed on every rendered checklist so the assessed publication is unambiguous — without it, renders can only show the short manuscript_id. You have the paper in hand; format the reference from its title page.

document is EITHER the raw manuscript text OR a file path — but the path must be readable on the SERVER host. If you are an agent whose uploaded files live on your own filesystem (a mounted upload dir, a sandbox), the server cannot see them: paste the manuscript TEXT instead, or use parse_pmcid for an open-access PMCID. Reach for a file path only when the file is on the same host as this server (server-local/batch use). A path-looking string that the server can't find raises rather than being silently ingested as its own text.

supplements is a list of server-readable file paths (PDF/docx/text) to merge as supplementary material — PASS IT WHEN YOU HAVE IT: TTE methods (estimand, identifying assumptions) frequently live in a supplementary protocol table, and without a supplement the verdicts on those leaves come back not_reported when the content was merely in an un-ingested appendix. When supplements are provided, supplement_status defaults to 'user_provided'. Pass supplement_status='none_exists' to assert the article has no supplement. section_hints is a LAST RESORT for a section the detector cannot find: {'introduction': 6543} splits whatever section contains that character offset. Some journals print no heading for a section (an introduction that simply follows the abstract) and interpose prose — a lay-summary box — that no structural rule can tell apart from the section itself; check the warnings for 'may have swallowed an unheaded introduction'. A hint never edits the text, so text_sha256 is unchanged and a hinted parse is the same document; the hinted section carries an empty heading because the paper prints none. Only supply an offset you established by READING the paper, and expect an error rather than silence if the hint cannot be applied.

Returns source-tagged section boundaries, protocol-table and flow-diagram detection over the combined text, supplement_status, and the text hash used to key later calls.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
citationNo
documentYes
supplementsNo
manuscript_idNo
section_hintsNo
supplement_statusNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceNo
n_pagesNo
citationNo
sectionsNo
warningsNo
documentsNo
full_textNo
text_sha256No
manuscript_idNo
extractor_versionNo
supplement_statusNo
flow_diagram_detectedNo
protocol_table_detectedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains server-side file visibility, error-on-missing-path behavior, the effect of hints on text_sha256, the default behavior of supplement_status, warnings about swallowed introductions, and the return payload. This is far beyond what the schema alone conveys.

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?

The description is long but front-loaded with its primary purpose and then organized by parameter. Every section earns its place because the tool has six parameters, several subtle failure modes, and important integration caveats. It could be tightened slightly, but the length is justified by the complexity.

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 purpose, parameter semantics, error behavior, defaults, alternatives, and return values. It even explains why supplements matter for TTE methods and what happens when citation is omitted. Given the tool's complexity, the absence of annotations, and 0% schema coverage, this description is remarkably complete.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate for every parameter, and it does. citation, document, supplements, supplement_status, and section_hints all receive detailed semantic guidance, including formats, defaults, failure modes, and examples. Only manuscript_id is left undocumented, but the critical parameters are thoroughly explained.

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 a specific verb and deliverable: 'parse a manuscript into a SectionMap with character-offset, source-tagged section spans.' This clearly distinguishes the tool from siblings like get_checklist, render_checklist, and assess_manuscript, and it identifies parse_manuscript as the 'PRIMARY entry point,' making its role in the pipeline unambiguous.

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?

The description gives explicit when-to-use and when-not-to-use guidance: paste text rather than a server-invisible path, use parse_pmcid for open-access PMCIDs, pass supplements when they exist, and reserve section_hints for last-resort section detection failures. It also names the alternative tool directly, so an agent can route correctly without guessing.

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