Skip to main content
Glama

submit_document

Submit a document for indexing on OpenArx. Supports LaTeX, Markdown, and PDF formats. Returns a core_document_id for status tracking. Published documents are immutable. To correct or update one later, publish a new version rather than editing in place. 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.
titleYesDocument 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? }].
licenseNoLicense (e.g. cc-by-4.0)cc-by-4.0
abstractYesDocument abstract
arxiv_idNoarXiv identifier, if cross-posted.
keywordsNoKeywords
languageNoDocument language (ISO 639-1)en
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.
categoriesNoList 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? }].
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.7/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses key behaviors: immutability of published documents, file-only content (no inline text), mutual exclusivity of content sources, limits, dry_run behavior (no charges, no commit), and the response structure. It covers all important traits for safe and effective use.

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 well-structured, starting with the main purpose and then detailing content options, limits, and dry_run. It is front-loaded and avoids redundancy, though it could be slightly more concise given its length. Overall, it efficiently conveys necessary information without waste.

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's 27 parameters, no output schema, and 4 required fields, the description is highly complete. It covers the main output (core_document_id), validation behavior, interactions with create_upload_url, and all constraints. An agent has sufficient information to use the tool correctly without external references.

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: it explains the purpose of each parameter, the mutual exclusivity of content_archive_base64 and content_ref, preferences for content upload method, detailed limits, and the dry_run response format. This greatly aids correct parameter selection and usage.

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 document for indexing on OpenArx,' which is a specific verb and resource. It distinguishes from sibling tools like create_upload_url by noting when to use the latter for large content. The supported formats and returned core_document_id are mentioned, making the purpose unambiguous.

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?

The description provides clear guidance on when to use create_upload_url for large files, when to set dry_run for validation, and how to handle updates via new versions. However, it does not explicitly contrast with all siblings (e.g., create_draft, publish_draft), leaving some selection context implicit.

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.