Skip to main content
Glama
Sign In
esa MCP Server

esa MCP Server

Official
by esaio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Prepend content to an existing esa post

esa_prepend_post
Destructive

Prepends Markdown content to an existing post's body without fetching the current body, saving it as a new revision. Optionally sets the WIP state.

Instructions

Prepends Markdown content to the beginning of an existing post's body, saving it as a new revision. Unlike esa_update_post, this does not require fetching the current body first. Behaves the same as esa_append_post except content is inserted at the start of the body. Optionally set wip to change the WIP state.

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": {
      "postNumber": "<postNumber>",
      "content": "<content>"
    },
    "name": "esa_prepend_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
wipNoWIP state after the insert. Defaults to the post's current WIP state
contentYesThe Markdown content to insert. Use 4 spaces for indentation. Line endings are normalized to LF. Include a blank line at the boundary to insert it as a separate block.
messageNoChange message. Defaults to "Updated via API." when omitted
teamNameNoTeam name (required). Use esa_get_teams first to see available teams.
postNumberYesThe post number to add content to

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.15.1
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.13.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already flag this as a destructive, non-read-only, closed-world mutation, so the safety bar is partly covered. The description adds real behavioral context beyond that: the change is recorded as a new revision and no read-modify-write cycle is needed. It stops short of stating what happens on a missing/invalid postNumber or what error responses look like.

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?

Three sentences, front-loaded with the core action, then followed by differentiation. The trailing 'Optionally set wip' sentence largely repeats the schema but is short enough not to be wasteful.

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 mutation tool with no output schema, the description covers the key semantics: insertion position, revision creation, the no-fetch workflow, and the append sibling. Nothing critical is missing, though failure modes and permission requirements are unaddressed.

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% and each parameter carries a substantive description, so the schema does the heavy lifting. The description only echoes the optional wip toggle, adding no format, default, or edge-case detail beyond what the schema already says.

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 ('Prepends Markdown content to the beginning of an existing post's body') and adds the persistence outcome ('saving it as a new revision'). It explicitly distinguishes itself from both esa_update_post and esa_append_post, so an agent can pick it without opening 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?

Names two siblings and the condition that selects each: esa_update_post when you would otherwise fetch the body first, esa_append_post when content goes at the end. The choice is fully determined by the description.

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