Skip to main content
Glama
Sign In

Prometheor

by com.prometheor
OverviewDiscussionsAdmin

Save a chat

save_chat
DestructiveIdempotent

Saves one of the owner's Claude Code web sessions or Claude project chats under a name of this account, so any AI of the owner can write to it with delegate web_session "" instead of its id. A Claude project's chat moves to a new session id when it restarts: save it with project (its claude.ai/code/project link) and every name of that project stays current. If you work inside a Claude project and know the current session of its project chat (for example from the session its messages to you come from), call save_chat with project, web_session and your own id as reply_session once at the start of your work (if the project chat moves, messages for it reach you and you pass them on); add name (the owner's name for it, else "Project chat " in the owner's language), which is used only when the project has no saved chat yet. Also use it when the owner asks; saving the same name again replaces the old id. remove: true deletes the name. list_agents shows the saved names. Threads (owner, 2 Nov 2026): as a thread of the project, also pass thread = your own thread's title, so other AIs can write to and read from you by it; if a tool of yours lists the project's threads, pass them all as threads (title, session_id, last_activity, resolved), which replaces the list kept so far (web_session may then be left out). Feed (only when a Prometheor feed request asks for it): pass the project chat's newest top-level messages as feed (id, at, from owner or claude, text); other AIs read them with read_chat.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "save_chat"
  }
}

Input Schema

NameRequiredDescriptionDefault
feedNoWith project, only when a Prometheor feed request asks for it: the project chat's newest top-level messages, as your project chat listing shows them. Secrets are removed and long messages shortened.
nameNoThe name the owner uses for the chat, e.g. "Project chat Shop".
removeNoDelete the saved name instead.
threadNoWith project and reply_session: your own thread's title as the project shows it (up to 60 characters are kept).
projectNoOnly for a Claude project's chat: the project's claude.ai/code/project link or id (chan_...).
threadsNoWith project: the project's whole thread list, as a tool of yours lists it; it replaces the list kept so far.
web_sessionNoThe chat's session id (session_...) or claude.ai/code link.
reply_sessionNoWith project, when you are a thread of that project: your own session id. If the project chat has moved, Prometheor passes messages for it through you.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / feed
      Added value: +{
+  "description": "With project, only when a Prometheor feed request asks for it: the project chat's newest top-level messages, as your project chat listing shows them. Secrets are removed and long messages shortened.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "at": {
+        "format": "date-time",
+        "type": "string"
+      },
+      "from": {
+        "description": "owner: a person wrote it; claude: the project chat's Claude.",
+        "enum": [
+          "owner",
+          "claude"
+        ],
+        "type": "string"
+      },
+      "id": {
+        "description": "The message's id (cmsg_...).",
+        "maxLength": 128,
+        "type": "string"
+      },
+      "text": {
+        "maxLength": 20000,
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "at",
+      "from",
+      "text"
+    ],
+    "type": "object"
+  },
+  "maxItems": 40,
+  "type": "array"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses that saving the same name replaces the old id, remove:true deletes the name, and that providing threads 'replaces the list kept so far'. It also explains project-chat session movement and feed trimming. However, it does not describe the return value or error behavior.

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 description is a single dense paragraph with run-on sentences and parentheticals ('Threads (owner, 2 Nov 2026):'). It is not front-loaded; critical conditions are buried mid-paragraph. While information-rich, it could be significantly more scannable and is difficult to parse as written.

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 an 8-parameter tool with no output schema, the description covers many edge cases (project chat moving, list replacement, feed trimming, thread passing). The main gap is lack of any return value or success/error indication, which is important given the absence of an output schema.

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 100% schema description coverage, the baseline is 3. The description adds meaningful cross-parameter relationships: 'with project, web_session and your own id as reply_session', 'web_session may then be left out' when threads are passed, and that name is 'used only when the project has no saved chat yet'—all of which clarify how parameters interact beyond their individual schema descriptions.

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 first sentence states a specific verb ('Saves'), resource ('Claude Code web sessions or Claude project chats'), and outcome ('under a name ... so any AI ... can write to it with delegate web_session'). It also clarifies the alternative to using session ids, immediately distinguishing it from sibling tools like delegate.

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?

The description provides explicit conditions for use: 'if you work inside a Claude project ... call save_chat with project, web_session and your own id as reply_session once at the start of your work' and 'Also use it when the owner asks'. It includes alternatives like list_agents for viewing saved names, but the guidance is scattered across the paragraph rather than front-loaded as a clear when-to-use block.

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

All Prometheor toolsInspect
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