Skip to main content
Glama

Export a Markdown Document

start_article_export
Read-only

Start an asynchronous export of the current saved document. Accepts natural workspace names and document titles; internal routing identifiers are optional. Pass the returned opaque jobId to get_article_export_status until the export completes. Use the identifier internally for polling and never show it to the user.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatYes
contextYesDescribe the user's underlying goal in one sentence. Do not include private document content, credentials, or personal information.
articleIdNoInternal document identifier when already available. Omit it when the user referred to the document by title.
workspaceIdNoOptional workspace ID to narrow document lookup. Omit when the document title or ID uniquely identifies a document across authorized workspaces.
articleTitleNoHuman-visible document title. Prefer this over asking the user for an internal document identifier.
workspaceNameNoOptional workspace name to narrow document lookup. A unique document title can be used without a workspace choice.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobIdYesOpaque export handle required by get_article_export_status. Use it for polling, but never show it to the user.
formatYes
statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / context
      Added value: +{
      +  "description": "Describe the user's underlying goal in one sentence. Do not include private document content, credentials, or personal information.",
      +  "type": "string"
      +}
    • changedInput schema / properties / workspaceId / description
      Previous value: -"Internal workspace identifier when already available. Omit it when the user referred to a workspace by name or has only one workspace."New value: +"Optional workspace ID to narrow document lookup. Omit when the document title or ID uniquely identifies a document across authorized workspaces."
    • changedInput schema / properties / workspaceName / description
      Previous value: -"Human-visible workspace name. Prefer this over asking the user for an internal workspace identifier."New value: +"Optional workspace name to narrow document lookup. A unique document title can be used without a workspace choice."
    • changedInput schema / required
      Previous value: -[
      -  "format"
      -]New value: +[
      +  "format",
      +  "context"
      +]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Adds real context beyond annotations: the job is asynchronous, returns an opaque jobId, and that ID should never be surfaced to the user. Annotations already cover safety (readOnly, non-destructive), so this addition of job-lifecycle and disclosure behavior is valuable.

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?

Three tight sentences: action first, then input guidance, then the mandatory polling step and ID-handling rule. No wasted words.

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

Completeness4/5

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

Covers the essential call pattern, required polling, and ID confidentiality for a tool with an output schema. Minor gaps: no mention of export formats or whether prior exports are cancelled, but the core behavior is complete.

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

Parameters3/5

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

Schema coverage is 83%, so the schema already documents format, context, articleId, workspaceId, articleTitle, and workspaceName. The description only reinforces the natural-name vs identifier preference, which the schema already states, so it adds little beyond the baseline.

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?

States a specific verb ('Start an asynchronous export') and resource ('current saved document'), with the async nature and handoff to get_article_export_status made explicit. Clearly distinct from get_article_export_status and convert_document.

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?

Explains the polling workflow via get_article_export_status and states that natural names are accepted over internal identifiers, but does not cover when to choose this over direct render_article or convert_document.

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.

Resources