Skip to main content
Glama

OpenArx

by ai.openarx

create_draft

Create an editable draft in the OpenArx Portal instead of publishing immediately. Returns a draft_id and an edit_url the user can open to review/edit before publishing. Drafts are file-only: first call create_upload_url, PUT your ZIP/PDF, then pass the returned file_id as content_ref. No content review runs and nothing is indexed — this is Portal workflow state, not corpus knowledge (drafts do not appear in get_my_documents). Optionally bind the draft to an existing document's version chain with previous_document_id, or preview with dry_run. The response always echoes a would_save block so you can confirm the server understood your inputs (which metadata keys were recognized, the resolved file details, and the version binding) before anything is published. The returned edit_url lets a person open and edit the draft in Portal before publishing. An agent cannot change a draft's CONTENT: there is no tool for that, so if the content needs to change, create a new draft. Metadata is different — title, authors, license and the rest can be supplied or corrected at publish time through publish_draft.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesDraft title
formatYesContent format
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.
dry_runNoSet true to validate inputs without creating the draft: runs the full validation pipeline (schema, previous_document_id ownership, content_ref magic-bytes), writes nothing to the Portal, does NOT consume the content_ref (a later real call with the same content_ref still succeeds), and returns the would_save echo with draft_id and edit_url null. Always free.
metadataNoOptional metadata block — same field set as submit_document (authors, abstract, license, funding, coi_statement, data_availability, related_identifiers, embargo_until, hubs, code_links, dataset_links, benchmark_links, doi, arxiv_id, source_url, arxiv_categories, …). Unrecognized keys are dropped; would_save.metadata echoes exactly the fields the server recognized — a key missing from that echo was a typo or unsupported.
content_refNofile_id from create_upload_url + PUT. The uploaded ZIP/PDF becomes the draft content (required — drafts are file-only).
previous_document_idNoOptional. Core document ID of the version this draft revises. When set it must exist AND be owned by you; the draft is then bound to that document's concept (version chain). Omit for a standalone draft.

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 carries full burden, and it excels: it discloses that drafts are not indexed, do not appear in get_my_documents, that dry_run does not consume content_ref, that the response echoes a would_save block, and that agents cannot edit draft content. These are non-obvious behavioral traits beyond the schema.

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 well-structured, with front-loaded purpose, then workflow, then caveats. Minor redundancy (edit_url mentioned twice) and a dense block of caveats warrant a 4 rather than 5, but every sentence adds useful information for a complex tool.

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 complexity (7 params, nested objects, no output schema), the description covers prerequisites, return values, side effects, limitations, and edge cases (dry_run, unrecognized metadata, version binding). It is fully complete for an agent to invoke the tool correctly and interpret results.

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?

Although schema coverage is 100%, the description adds substantial meaning: content_ref is required because drafts are file-only, metadata keys are dropped unless recognized and echoed, previous_document_id binds to a version chain, and dry_run validates without side effects. It clarifies run_id usage and ownership requirements, going well beyond schema descriptions.

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 resource: 'Create an editable draft in the OpenArx Portal instead of publishing immediately.' It clearly distinguishes from siblings like publish_draft and submit_document by emphasizing the draft workflow and returning draft_id/edit_url.

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?

Explicit workflow guidance is given: 'first call create_upload_url, PUT your ZIP/PDF, then pass the returned file_id as content_ref.' It also states when not to use (drafts are file-only, no content editing) and points to publish_draft for metadata correction. This fully supports tool selection and invocation.

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

All OpenArx toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources