Skip to main content
Glama
Sign In

Docfarm

by io.github.lavanry
OverviewDiscussionsAdmin

Host an HTML doc

host_html_content
Destructive

Host an HTML doc on docfarm and return its share link. A name that exactly matches an existing doc's title, ignoring case and surrounding spaces, overwrites that doc in place, keeping its share link, password, and view stats, so anyone holding the URL sees the new version. Any other name creates a new doc. A similar but different name, such as "Pricing" next to "Pricing final", also creates a new doc and leaves the other one untouched, and the response names that doc so you can offer to update it instead. To update a doc, reuse its exact title. Takes the HTML inline, so it works in any environment. For a small change to an existing doc, get_doc_html + patch_doc sends far less content. Every page is scored against the docfarm house standard on the way in and the score comes back in the response; call get_build_brief BEFORE you write the HTML so you meet the standard first time rather than fixing afterwards. Before you publish a NEW doc, call suggest_link, show the person the link it returns and ask whether they want a different ending, then pass the ending they settle on as slug.

Input Schema

NameRequiredDescriptionDefault
htmlYesFull HTML body
nameYesPage name. To update a doc, reuse its exact title, which keeps the share link. A new or merely similar name creates a new doc.
slugNoOptional. The link ending the person approved through suggest_link, the part after the last slash. Only used when this creates a new doc; an update keeps the doc's link. Omit it to make one from the name.
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.
replaceNoOmit normally. Set false to publish a new doc even when the name exactly matches an existing one, which gets a new share link. Set true only when the person asked to replace a doc and you do not have its exact title. It then also overwrites the one doc with a similar name, such as "Pricing v2" for "Pricing", and publishes nothing when no doc or several docs match.
brand_fromNoOptional. Name of an existing HTML doc in this farm whose brand assets this page uses. Required for any DF_ASSET_ token you wrote to resolve to real bytes. Get the tokens from get_build_brief first, then pass the same doc name here.

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, the part after the last slash. Only used when this creates a new doc; an update keeps the doc's link. Omit it to make one from the name.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Very rich beyond the annotations: it discloses exactly what an overwrite preserves (share link, password, view stats), what happens to similarly-named docs (untouched, and the response names them), the scoring-on-ingest behavior, and that the response carries the score. This is the meaningful context destructiveHint=true only hints at, and nothing contradicts the 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?

Front-loaded with the core host/overwrite behavior and each sentence carries operational weight. It is long for a tool description, though, and the name-matching rule is repeated almost verbatim in both the description and the `name` schema field.

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?

With no output schema, the description still tells the agent what comes back (share link and standard score) and covers the full publish workflow, the account scoping, and the brand-asset prerequisite. Nothing an agent needs to call this correctly for a 6-param tool is missing.

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 beyond the schema: the case/whitespace-insensitive exact-match rule for `name`, and the workflow ordering that determines when `slug` applies (only for new docs, after suggest_link approval). It largely restates schema content for `replace` and `brand_from` rather than extending it, keeping it below 5.

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 ('Host an HTML doc') plus the return value (its share link), and cleanly separates itself from siblings by explaining that exact-title matches overwrite while similar names create new docs. An agent can distinguish this from patch_doc or duplicate_doc without reading any schema.

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 explicit routing conditions: use `get_doc_html` + `patch_doc` for small changes, call `get_build_brief` before writing HTML, and call `suggest_link` before publishing a new doc to get the user-approved slug. Names concrete alternatives and the conditions that select them.

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