Skip to main content
Glama

Edit a post

edit_post

On one site of the account, named in site. One change to a post's Markdown: find must match exactly once in the post as get_post shows it (include enough surrounding text to be unique), and is replaced by replace. The whole body is re-read after, so a block fence changed here changes its block, and a {{members_count}} stays a live value. The write is a revision the writer can undo. For many changes, replace_post. To add a picture, put it into the library with upload_media first, then paste the Markdown it answers.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>",
      "post_id": "<post_id>",
      "find": "<find>",
      "replace": "<replace>"
    },
    "name": "edit_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
findYesText that appears exactly once in the post's Markdown
siteYesThe site to work on, as list_sites names it
post_idYes
replaceYesWhat takes its place; empty removes it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations it discloses that the write is an undoable revision, that the whole body is re-read after the edit (so a fence change alters block structure), and that template placeholders like {{members_count}} stay live. These are exactly the side effects an agent needs and none are derivable from readOnlyHint=false / destructiveHint=false.

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 and front-loaded, with the constraint, the side effects, and the alternatives in a compact order. The opening fragment 'On one site of the account, named in site.' is syntactically awkward and costs a little readability.

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?

For a non-idempotent mutation with no output schema, the description covers the match constraint, side effects, undoability, and sibling routing. It does not say what comes back after the edit or how it interacts with the editing-session tools, which are the remaining meaningful gaps.

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 75%, and the description adds genuine meaning for `find`: it must match exactly once and should carry enough surrounding text to be unique. `site` is clarified as the name from list_sites. Only `post_id` receives no explanation in either place, which keeps this just short of full marks.

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?

The description states a precise verb and scope: a single Markdown substitution on one post of one named site. It distinguishes itself from the sibling that handles bulk changes (replace_post) and from get_post by tying the match to how get_post renders the body.

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?

It explicitly routes multi-change work to replace_post and image insertion through upload_media first, which is real when-to-use guidance. It leaves a gap around the editing-session siblings (start_editing_post, finish_editing_post), so an agent cannot tell from this text whether a session must be opened first.

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