Skip to main content
Glama

edit

Update lore items via append, overwrite, section replacement, supersede, or status and level changes. Also manage tags and links.

Instructions

edit(id, action=, ...) — 4 write modes (action). If action is omitted, defaults to append (msg alone works too).

Write modes (action, tool option = behavior match):

  • append (default, non-destructive) → edit(id, action='append', msg='new content') # or omit action, msg alone — appends to the end of body, keeps the rest

  • section (partial edit) → edit(id, action='section', section='heading', msg='new section content') # replaces just that section (existing heading only — errors if missing; to add a new section use append), keeps the rest

  • overwrite (full replace) → edit(id, action='overwrite', msg='new body' [, tags=[...], ...]) # old body kept in history(recoverable via log). tags/items(doc only)/links are also fully replaced in the same call

  • supersede (follow-up publish) → edit(id, action='supersede', msg='new conclusion') # creates a new id, old one head=False

(action= is one of append|section|overwrite|supersede. Unspecified('') means append.)

Other:

  • mark as dropped → edit(id, status='dropped') (still shown in search)

  • level (lore importance) → edit(id, level=N): 1=note(default) 2=verified 3=pinned(shown in brief) 4=global(all projects)

  • supersede chain (keep old + new head) → edit(id, action='supersede', ...) (or add(type='lore'|'doc', relates=old_id, ...))

  • supersede by an existing item (reconcile a contradiction) → link(a=X, b='lr-Y'|'dc-Y', action='supersede') (X→head=False)

  • permanent delete → rm(id)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
msgNo
flowNo
helpNo
tagsNo
itemsNo
levelNo
linksNo
titleNo
actionNo
statusNo
sectionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Without annotations, the description reveals key behaviors: overwrite keeps old body in history (recoverable via log), supersede creates a new id, and section mode errors if the heading is missing. It also notes that marking as dropped still shows in search. This covers the major behavioral traits, though it omits authorization or rate limit details.

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?

The description is long but well-structured with bullet points and examples, making it easy to parse. It front-loads the core concept ('4 write modes') and then details each. Some redundancy exists (e.g., supersede mentioned twice), but overall it is efficient for the complexity.

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?

Given the tool's complexity (12 params, multiple modes) and the absence of annotations, the description covers the main use cases and behaviors. However, it leaves some nuances unclear, such as how non-action parameters interact with different modes (e.g., are tags ignored when appending?). The presence of an output schema reduces the need to explain return values, but the description could further clarify overall effects.

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?

The input schema has no descriptions (0% coverage), so the description compensates by explaining most parameters: id, msg, action, section, status, level, tags, items, links. It provides concrete examples for each action. However, 'flow' and 'help' are not explained, and 'title' is only briefly mentioned. The description adds significant meaning beyond the schema.

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 clearly states that 'edit' modifies existing content with four distinct write modes (append, section, overwrite, supersede). Each mode is explicitly described with verb+resource (e.g., 'appends to the end of body'). The tool's purpose is unambiguous, and the modes differentiate it from siblings like 'add' or 'rm'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides within-tool guidance on which action mode to use for specific edits (e.g., append for adding, section for partial edit, overwrite for full replace). It also mentions alternatives like 'rm' for permanent delete and 'link' for supersede. However, it does not explicitly tell when to use 'edit' versus other sibling tools like 'add', 'config', or 'status', leaving some ambiguity for cross-tool decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/linklore/linklore-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server