Skip to main content
Glama
Sign In
Memorable MCP Server

Memorable MCP Server

by leouofa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

memorable_update_memory

Update a stored memory's title, Markdown body, or pinned status by ID in Memorable, so you can revise saved context and keep pinned items in order.

Instructions

Update a memory's title, Markdown body, or pinned status in Memorable

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": {
      "id": "<id>"
    },
    "name": "memorable_update_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesUnique identifier of the memory
bodyNoUpdated Markdown content of the memory
titleNoUpdated title of the memory
pinnedNoUpdate pinned status
pinned_positionNoUpdate pinned position index
render_markdownNoWhether to return rendered HTML in the response

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. It says nothing about partial-update semantics (are omitted fields preserved?), how pinned_position interacts with pinned, whether changes are reversible, or what permissions are required for a mutation.

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?

A single front-loaded sentence with zero filler that names the resource and the mutable fields immediately. It is efficient, though its brevity is as much a symptom of missing detail as of tight writing.

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?

The fully described schema offsets some of the gap for a six-parameter mutation tool, and no output schema means return values need not be explained. Still, with no annotations and overlapping siblings, an agent lacks the guidance needed to safely choose this tool over toggle_pin or reorder_pinned.

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%, so all six parameters are already documented in the schema, making 3 the baseline. The description restates title, body, and pinned but adds no meaning beyond the schema — notably omitting id, pinned_position, and render_markdown.

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 uses a specific verb ("Update") on a specific resource ("a memory") and enumerates the mutable fields: title, Markdown body, and pinned status. That distinguishes it from siblings like memorable_create_memory and memorable_delete_memory, though it doesn't explicitly contrast with memorable_toggle_pin or memorable_append_to_memory.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance. The 'pinned status' scope overlaps with memorable_toggle_pin and memorable_reorder_pinned, yet the description never says which tool to prefer, leaving the agent to infer routing from names alone.

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