Skip to main content
Glama
Sign In

Docfarm

by io.github.lavanry
OverviewDiscussionsAdmin

Edit a doc (snippet patch)

patch_doc
Destructive

Edit an existing hosted doc by replacing a snippet of its HTML. DEFAULT TOOL for ANY edit to a doc the user already has — typo, copy change, restyle, new section, anything. ~50 tokens instead of ~7000 for re-hosting. Workflow: (1) if you don't have the current HTML in context, call get_doc_html first to read it. (2) construct before_snippet as a unique chunk of the existing HTML and after_snippet as its replacement. Pass EITHER doc_name (easiest) OR slug. Ambiguous match → fails with context for each candidate. Preserves share link, password, view counts, comments. Patching sends only the changed snippet, so it costs far less than re-sending a whole doc. For several edits at once ("fix the typo AND change the CTA AND update the date") pass a patches array instead of before/after: all of them land atomically or none do, each validated after the previous one applied.

Input Schema

NameRequiredDescriptionDefault
slugNoShare-link slug or full URL. Alternative to doc_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.
patchesNoSeveral edits applied atomically. Use this OR before_snippet/after_snippet.
doc_nameNoName of the doc to edit (same name you passed to host_html_content). Use this if you don't have the slug.
after_snippetNoReplacement text. For a single edit.
before_snippetNoExact text to find (must be unique unless occurrence_index given). For a single edit.
occurrence_indexNo0-based index of which match to replace when before_snippet isn't unique

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / patches / items / additionalProperties
      Added value: +false
  2. 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 destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: preserved state (share link, password, view counts, comments), atomic all-or-nothing semantics for patches, sequential validation, and failure behavior on ambiguous matches. It does not, however, state permission/auth requirements for the edit itself.

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?

Dense but well front-loaded — the default-tool claim and cost rationale come first, then the workflow. It is long, and the cost-saving point is restated twice ("~50 tokens instead of ~7000" and "costs far less than re-sending"), which is slight redundancy.

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?

For a 7-param mutation tool with no output schema, the description covers the full workflow, the alternative invocation mode, atomicity, preserved state, and failure modes. Nothing an agent needs to invoke it correctly 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 meaning: the either/or relationship between doc_name and slug, that before_snippet must be a unique chunk, and that patches is an alternative to the single-snippet params. occurrence_index is left to the schema, which handles it adequately.

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 (edit) and resource (existing hosted doc) with the exact mechanism (replace a snippet of HTML). It explicitly positions itself as the default against siblings like host_html_content and re-hosting, so an agent can distinguish it without opening other schemas.

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?

Provides explicit when-to-use ("DEFAULT TOOL for ANY edit"), a numbered workflow, the prerequisite of calling get_doc_html first, the choice between single before/after and a patches array, and doc_name-vs-slug selection. Ambiguity handling ("fails with context for each candidate") is also disclosed.

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