Skip to main content
Glama
B-C-Software

Doconda

Official
by B-C-Software
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create document

create_document

Turn a request or Markdown into a finished Word, PDF, PowerPoint, Excel file or web artifact, and get download links once it is ready.

Instructions

Create a finished document: Word, PDF, PowerPoint, Excel or an artifact (a web page with its own shared database, e.g. a poll or a team checklist). Choose only the format: Doconda works out what kind of document it is (contract, letter, report…) from the request. Give prompt to have it written, or markdown with the content already written. Waits until it is ready and returns download links.

Input Schema

NameRequiredDescriptionDefault
dataNoArtifacts only. shared (default): everyone with the link sees the same data (polls, team lists). local: each visitor keeps their own in their browser (calculators, personal checklists). With retention none, only local.
nameNoOptional: a name to find it later, e.g. 'Contrato piso Malasaña'. It also names the files.
styleNoOptional: the look in plain words, e.g. 'blue centred headings, Lora font, page numbers, table of contents'.
formatNodocx → Word (+ PDF); pdf → only the PDF; pptx → PowerPoint (+ PDF); xlsx → Excel (+ PDF); artifact → web page. If the user didn't say, leave it out and Doconda decides from the prompt.
promptNoWhat to write, in the user's words (topic, audience, length, tone). Formatting wishes too, e.g. 'blue centred headings, with a cover page'.
qualityNoOptional. fast: the cheapest and quickest (about a minute), any style, but it can't copy a file's design. standard: more care, takes minutes. best: the highest quality and price, e.g. to copy a file's design or to edit with comments or tracked changes. auto (default): Doconda picks the level the request needs. The price of the highest level it may use is held from the balance while the document is made and what is not used is returned: with a low balance, pick fast or set max_quality.
markdownNoContent already written, in Markdown (instead of prompt). For an artifact, the content its page shows.
retentionNoOptional: how long Doconda keeps it once finished (none = 15 minutes). Without it, the project's retention (30 days unless changed). The user should save the file before then.
max_qualityNoOnly with quality auto: the highest level Doconda may choose. It caps the price and the amount held, e.g. standard.
source_file_idsNoUploaded files (upload_file) or documents already made (their id, from list_documents): documents to base the text on (up to 5, with prompt) and pictures to put in the document (up to 10; with markdown, refer to them as ![caption](img:1), the first picture).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.5
    • addedInput schema / properties / max_quality
      Added value: +{
+  "description": "Only with quality auto: the highest level Doconda may choose. It caps the price and the amount held, e.g. standard.",
+  "enum": [
+    "fast",
+    "standard",
+    "best"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / quality
      Added value: +{
+  "description": "Optional. fast: the cheapest and quickest (about a minute), any style, but it can't copy a file's design. standard: more care, takes minutes. best: the highest quality and price, e.g. to copy a file's design or to edit with comments or tracked changes. auto (default): Doconda picks the level the request needs. The price of the highest level it may use is held from the balance while the document is made and what is not used is returned: with a low balance, pick fast or set max_quality.",
+  "enum": [
+    "auto",
+    "fast",
+    "standard",
+    "best"
+  ],
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare readOnly=false, non-idempotent, non-destructive, so the mutating nature is already covered; the description adds genuinely new behavioral facts beyond that: the call blocks ('Waits until it is ready') and the result is download links. It does not mention failure modes, credential/quota prerequisites, or that repeated calls produce duplicates (implied only by idempotentHint=false in annotations).

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?

Four sentences, front-loaded with the capability and output formats, then the input fork, then the wait/return. Zero filler, though the parenthetical artifact explanation is slightly dense and the prompt/markdown fork could be tighter. Well within size for a 10-parameter tool.

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?

No output schema exists, and the description compensates by telling the agent the call is synchronous and yields download links. Combined with exhaustive schema docs for cost, retention and quality, an agent has enough to invoke it correctly; only error/edge behavior and the create-vs-edit boundary are left implicit.

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 description coverage is 100%, so the schema already documents all 10 parameters, including enums, defaults, the format→output mapping, the retention/balance-hold nuance and the max_quality/quality relationship. The description only restates the format and prompt/markdown choices, adding no syntax or edge-case meaning the agent could not read in the schema. Baseline 3 is correct.

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 and resource ('Create a finished document') and enumerates the concrete outputs (Word, PDF, PowerPoint, Excel, artifact), including a plain-language definition of the non-obvious 'artifact' format. An agent can distinguish this from sibling upload_file (which supplies inputs) and edit_document (which modifies an existing one) without opening either schema.

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?

Gives explicit selection guidance: 'Choose only the format' and the prompt-vs-markdown fork ('Give prompt to have it written, or markdown with the content already written'). It stops short of naming edit_document or review_document as the alternatives for non-creation work, so the when-not-to-use boundary is only implied by the verb 'create'.

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

Deploy Server

Other Tools