Prometheor

Save a logbook entry

prometheor_append_checkpoint

Idempotent

Saves one memory to the account's logbook; it takes no projectId. This is an idempotent, provenance-bound checkpoint without canonical overwrite authority. logEntry marks a logbook entry as a decision, status or result. The user's own automatic_saving setting, returned by a recall, decides whether such logbook entries are saved without a separate request: when it is on, logbook entries only; other memories, and everything while it is off or unknown, only on the user's explicit request. Private and do-not-save requests are respected. Automatic saving keeps only a thin logbook: a decision that was made, a change in the status of the user's work (started, blocked, finished, a milestone reached) or a verified result. Save anything else, such as who the user is, preferences, people, tools or plans, only when the user explicitly asks. Write one entry per memory as a short standalone statement in plain language (at most three sentences), with a title of at most eight words. Do not save step-by-step progress, raw logs or command output, test or example data, small talk, or anything already saved; if a recalled memory already covers it, skip saving. Never save health, religion, political views or other sensitive details unless the user explicitly asks. Topics: about = who you are: role, background, where you live and work; preferences = how you like answers, tone, language and formats; work = projects, goals, decisions and their current state; tools = stack, apps, devices and how you set them up; people = people who matter to you and places you know; plans = upcoming events, deadlines and travel with a date; life = hobbies, learning, sport and weekly routines.

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": {
      "sensitivity": "<sensitivity>",
      "title": "<title>",
      "body": "<body>",
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "prometheor_append_checkpoint"
  }
}

Input Schema

Name	Required	Description
`body`	Yes
`title`	Yes
`topic`	No	Where this memory belongs, so the user sees it sorted by topic.
`logEntry`	No	Marks a logbook entry: a decision that was made, a change in the status of the user's work, or a verified result. Required for every proactive save while automatic_saving is on; omit it for a memory the user explicitly asked to save. The entry is filed under the work topic with its kind in the title.
`memoryUse`	No	Optional negative policy for this request only. read_only permits recall but refuses checkpoint writes and returns automatic_saving off; disabled refuses recall and writes before Memory access. Omitting this field does not authorize retrying previously denied content. It does not identify a native temporary chat or alter account settings.
`sensitivity`	Yes
`idempotencyKey`	Yes
`memoryGeneration`	No	Echo memory_generation from the current recall after a reset. Defaults to zero for older clients. Never upgrade and retry a pre-reset write automatically; use only newly supplied user input or explicit fresh approval.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations' write and idempotency profile, it discloses provenance binding, lack of canonical overwrite authority, thin-logbook behavior, privacy constraints, and duplicate suppression. These details substantially clarify what will and will not be persisted.

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

Conciseness3/5

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

The purpose and key checkpoint behavior are front-loaded, and most content is operationally useful. Nevertheless, the dense single paragraph repeats the decision/status/result taxonomy and explicit-request rule, making the lengthy policy harder to scan.

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 complex eight-parameter write tool, it supplies unusually complete saving policy, content formatting, topic taxonomy, and privacy context. The undocumented required sensitivity and idempotencyKey semantics, unexplained provenance terminology, and absence of result or failure behavior leave some invocation 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?

With 50% schema coverage, the description compensates well by defining every topic, constraining body and title style and length, and explaining logEntry usage. However, it does not define the required sensitivity values or explain how to construct and reuse the required idempotencyKey.

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 opening clearly states the verb, resource, and scope: saving one memory to the account's logbook without a projectId. The checkpoint and overwrite-authority language adds useful scope but is jargon-heavy, and there is no explicit differentiation from siblings such as save_chat.

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?

It gives explicit selection rules based on automatic_saving, distinguishes proactive logbook entries from memories requiring an explicit user request, and lists content that must be skipped. Duplicate-recall handling, private requests, and sensitive-topic restrictions provide strong when-not-to-use guidance.

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

All Prometheor tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?