Skip to main content
Glama
patchloom

Patchloom

Official
by patchloom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

md_insert_after_section

Destructive

Insert Markdown content after a full section body to add a sibling section. Use for adding a new '##' block after another section's content.

Instructions

Insert content after the full section body (sibling placement). Use when adding a new ## section after this section's content. Prefer md.insert_after_heading for content under the heading line. Inserts after the full section body (sibling placement). Prefer md_insert_after_heading for content under the heading. Example: {"content":"## FAQ\n\nCommon questions.\n","path":"README.md","heading":"## Config"}

Input Schema

NameRequiredDescriptionDefault
pathYes
contentYes
headingYes
agent_presetNoWhen true, replace uses the agent preset: unique, require_change, fuzzy floor 0.90, allow_absent_old false. Off unless set.
expected_sha256NoSHA-256 hex of the file's current bytes. If it does not match, the tool returns error_kind stale and writes nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.32.6
    • addedInput schema / properties / agent_preset
      Added value: +{
+  "default": false,
+  "description": "When true, replace uses the agent preset: unique, require_change, fuzzy floor 0.90, allow_absent_old false. Off unless set.",
+  "type": "boolean"
+}
    • addedInput schema / properties / expected_sha256
      Added value: +{
+  "description": "SHA-256 hex of the file's current bytes. If it does not match, the tool returns error_kind stale and writes nothing.",
+  "type": "string"
+}
  2. First observedv0.32.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds placement semantics (sibling vs. under-heading), which is useful, but says nothing about the mutation being applied to a live file, whether it is idempotent, or how expected_sha256/stale errors change behavior beyond what the schema states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core sentence 'Insert content after the full section body (sibling placement)' appears twice and the routing advice to md_insert_after_heading appears twice in slightly different forms. Roughly half the text is redundant, so the definition is not front-loaded efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and for a destructive write tool the description does supply placement semantics plus a concrete example, which is adequate. It still omits anything about failure modes, atomicity, or what the tool returns on success, leaving gaps against the mutation complexity.

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 only 40%: path, content and heading carry no schema descriptions, and only agent_preset and expected_sha256 are documented. The worked example does demonstrate how path, heading and content combine, which partially compensates, but it is thin for a five-parameter mutation tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (insert content after a full section body) and explicitly distinguishes itself from the sibling md_insert_after_heading. However, the purpose is stated twice in near-identical wording, which muddies rather than sharpens the message.

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 gives an explicit when-to-use condition ('adding a new ## section after this section's content') and names the alternative plus the condition that selects it ('Prefer md.insert_after_heading for content under the heading line'). The only flaw is that the alternative is referenced twice and the dotted name doesn't exactly match the sibling tool name.

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