Skip to main content
Glama
Sign In

Docfarm

by io.github.lavanry
OverviewDiscussionsAdmin

Publish an uploaded doc

finalize_upload
Destructive

FAST PATH step 2/2: after PUTting the file to the signed URL from get_upload_url, call this to publish. NEW name → new doc + share link. Name matching an EXISTING HTML doc → updated in place, same share link. Verifies the uploaded object exists before publishing.

Input Schema

NameRequiredDescriptionDefault
nameYesDoc name — same rules as host_html_content (existing name = in-place update).
slugNoOptional. The link ending the person approved through suggest_link. Same rules as host_html_content.
accountNoEmail address of the farm to act on. Omit for the signed-in farm. Only a connected account is accepted; call list_accounts to see which.
upload_pathYesThe upload_path value returned by get_upload_url.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / slug
      Added value: +{
+  "description": "Optional. The link ending the person approved through suggest_link. Same rules as host_html_content.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true; the description reinforces this by disclosing the in-place overwrite path and that it 'verifies the uploaded object exists before publishing' (a pre-flight validation the agent should anticipate failing). It stops short of describing the return payload or what happens to the previous doc version, so it adds context but not a full behavioral picture.

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, zero filler, with the step-sequencing front-loaded before the outcome branches. Every clause carries operational information the caller needs.

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?

There is no output schema, but the description states the observable outcome of both branches (new doc + share link, or same share link retained), which is what an agent most needs. It does not say what the call itself returns (URL, status, or id), leaving a small gap for a publish operation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics for `name` (new vs. existing determines create-vs-update) that the schema only gestures at via 'existing name = in-place update'. `slug` and `account` semantics are left to the schema, which is acceptable given full coverage.

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 ('call this to publish' the uploaded doc) and situates itself precisely as 'FAST PATH step 2/2' following `get_upload_url`. The name-collision rule ('NEW name → new doc', 'matching EXISTING HTML doc → updated in place') separates it from sibling writers like host_html_content and patch_doc.

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?

Gives an explicit precondition ('after PUTting the file to the signed URL from get_upload_url') and names that sibling as the required prior step. It also tells the agent the two outcome branches keyed on `name`, so the caller knows which behavior to expect before invoking.

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

All Docfarm toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources