Skip to main content
Glama

create_new_version

Submit a new version of an existing document. The earlier version is not replaced: it keeps its own identifier, so an existing citation of it still resolves to the exact text it referred to. The previous version's chunks will be marked as not-latest. Omit categories, keywords, or language to inherit each independently from the previous version; pass a value to override. Content is file-only: provide a base64-encoded ZIP archive (content_archive_base64) OR a content_ref from an out-of-band upload — exactly one. A ZIP may hold a single PDF, markdown + figures, or multifile LaTeX. Inline text is no longer accepted. For content above ~10 KB, prefer create_upload_url → PUT the file to the returned URL → pass the returned file_id as content_ref (avoids base64 token bloat). content_archive_base64 and content_ref are mutually exclusive — provide exactly one. Limits: title ≤5,000 chars; abstract ≤50,000 chars; archive ≤50 MB; keywords ≤50 items × ≤100 chars each. Set dry_run=true to validate without committing: no document is created, nothing is queued, no credits are charged; the response shows what would be saved and the estimated cost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doiNoDOI of the work.
hubsNoPortal hub / topic slugs to associate.
titleYesUpdated title
run_idNoOptional. The active methodist run_id (as returned by the methodist diagnose / get_current_dose door). Pass it whenever you call this tool while working inside a run, so the call is attributed to that run for the §8 usage crosscheck — attribution is run-anchored, so it stays correct even if your access token refreshes mid-run. Must be YOUR run: a run_id owned by a different principal, or a non-existent run_id, is rejected.
authorsYesAuthor list
dry_runNoValidate only — no document created, no file written, no queue entry, 0 credits. Response: {dry_run:true, validation:"ok", estimated_cost, would_save}.
fundingNoFunding sources, e.g. [{ funder_name, award_number? }].
licenseNoLicensecc-by-4.0
abstractYesUpdated abstract
arxiv_idNoarXiv identifier, if cross-posted.
keywordsNoOverride. Omit to inherit from previous version.
languageNoOverride (ISO 639-1). Omit to inherit from previous version.
main_fileNoFilename within the archive to treat as primary content. If exactly one .pdf / .tex / .md file exists at the archive root, auto-inferred when omitted. Otherwise required. For a content_ref ZIP this selects the entry; ignored for a content_ref single file.
categoriesNoOverride. Omit to inherit from previous version. List of subject categories. arXiv format recommended: `{domain}.{subcategory}` where domain is lowercase (with optional hyphens) and subcategory is two uppercase letters. Examples: "cs.CL" (Computation and Language), "math.PR" (Probability), "cond-mat.str-el" (Strongly Correlated Electrons), "physics.gen-ph" (General Physics). Other formats accepted but may render inconsistently in search facets.
code_linksNoSource-code repositories, e.g. [{ url }].
source_urlNoCanonical source URL.
content_refNofile_id from a successful create_upload_url + PUT upload flow. The uploaded ZIP / PDF / LaTeX / Markdown becomes the document content. Mutually exclusive with content_archive_base64.
coi_statementNoConflict-of-interest statement.
dataset_linksNoDatasets, e.g. [{ name, url? }].
embargo_untilNoISO-8601 timestamp; the document is embargoed until then.
content_formatYesContent format
benchmark_linksNoBenchmark-result references.
arxiv_categoriesNoarXiv subject categories.
data_availabilityNoData-availability statement or status.
related_identifiersNoRelated identifiers, e.g. [{ identifier_type, identifier_value, relation? }].
previous_document_idYesCore document ID of the previous version
data_availability_urlNoURL to the dataset / data-availability record.
content_archive_base64NoBase64-encoded ZIP archive (PK\x03\x04). Must contain main_file plus any attachments. Mutually exclusive with content_ref. Prefer content_ref (create_upload_url) above ~10 KB.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: the new version does not replace the old, previous chunks become 'not-latest', dry run shows validation without committing, and effects of omitted parameters (inherit from previous version). Limits and format requirements are also detailed.

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 fairly long but front-loaded with the most critical information. Every sentence adds necessary detail, though some reorganization could make it even more scannable. No redundancy.

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?

Given the tool has 28 parameters, no output schema, and no annotations, the description is remarkably complete. It covers all key aspects: behavior, constraints, content handling, inheritance, dry run, and limits. The agent can confidently use this tool based on the description alone.

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?

Despite 100% schema coverage, the description adds significant value beyond the schema: explains mutual exclusivity of content parameters, inheritance for categories/keywords/language, dry run specifics, file format expectations for ZIP contents, and preference for content_ref over base64 for large files.

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 clearly states 'Submit a new version of an existing document' and distinguishes it from similar operations by noting that the earlier version is not replaced and keeps its own identifier. This differentiates it from sibling tools like submit_document (new document) or publish_draft.

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 provides explicit guidance on when to use this tool, including content upload alternatives (content_ref preferred above ~10 KB), dry run for validation, and inheritance behavior for omitted fields. It also clarifies mutual exclusivity of content_archive_base64 and content_ref, and that inline text is no longer accepted.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation4/5

Most tools have clear distinct purposes, but some overlap exists between explore_topic and methodist_explore_topic, and between find_related and find_related_claims. Descriptions generally differentiate them well.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern with methodist_ prefix for research workflow tools, though 'paginate' and 'methodist' (without underscore) are minor deviations.

Tool Count2/5

35 tools is too many for a single server's scope, exceeding the 25+ threshold. The server combines two major workflows (literature search and research process guidance), which would be better split.

Completeness4/5

The tool set covers a wide range of operations: multiple search modes, document submission and versioning, topic exploration, evidence checking, methodology search, and research guidance. Minor gaps include lack of document deletion or metadata update without new version.