Skip to main content
Glama

Save notes to Eigma

eigma_save_notes
Idempotent

Use this when the user asks to save, file, keep, note, or remember THIS conversation (or part of it) into their Eigma wiki. It drafts the pages worth keeping and saves them to the user's Eigma review inbox in this one call, then ends the request. Only durable, learn-worthy knowledge becomes pages (skip look-up trivia, logistics, and small talk), so a conversation with nothing worth keeping yields no draft and nothing saved. Editing pages that ALREADY exist is eigma_suggest_edits' job. Give every page a fitting category_path: an existing chapter when one fits, and a new chapter when the concept belongs to none of them rather than forcing it into an unrelated one. To get that right, call eigma_resolve_pages FIRST, once, with every page you drafted: it returns, per draft, the existing pages it may duplicate and the wiki's real chapters. Reuse a returned page's title AND category_path exactly to update it, and for any page you update call eigma_read_page on it FIRST: saving REPLACES that page's body, so body_md must carry BOTH what the page already says AND what this conversation adds - every sentence you leave out is deleted from the user's wiki, and an update body written from the conversation alone destroys the page. Do not browse the whole wiki for this. Pass nodes (one object per page) plus the top-level conversation block. Every page object needs ALL of: title (the concept's plain canonical name as a 1-3 word noun phrase, with NO appended source or qualifier, so it matches and updates any existing page on that concept), category_path (the CHAPTER the page lives under, never the page's own title; normally ONE level, 2 only if unusually specific; reuse a fitting existing chapter over inventing a near-duplicate, and create a new chapter when none of them fits), body_md (a STRUCTURED page: a lead paragraph then ## sections; write math as LaTeX in $...$/$$...$$; ONLY if the chat used outside sources, add [^N] footnotes and one ## References section, each definition written as "[^N]: label" carrying the source's REAL link (a bare source name with no URL becomes a dead, unclickable reference)), summary (ONE short line), links (related concept titles, including exact existing-page titles, to connect the graph), and quizzes (1-3, REQUIRED, each an understanding-testing selection question {kind,prompt,options,answer}; no option may run more than half again as long as the shortest, reached by making each wrong option a MORE substantial claim, never by shortening the right one). Draft every page in FULL now: whatever you send is EXACTLY what lands in the user's review inbox, so a missing field saves an incomplete page. The body_md MAY also include a mermaid diagram and/or ONE self-contained animation widget (all JS/CSS inline, no external network); most pages need neither. This call SAVES the pages into the user's Eigma review inbox and returns a receipt listing what it saved as NEW or as an UPDATE; show that receipt to the user, then end your turn - unless the receipt itself says pages did not fit, in which case call this again with exactly those remaining pages first. This is the only call that WRITES (eigma_resolve_pages before it only looks things up). Saving the same pages twice is harmless (the server ignores a duplicate), so if the user asks again, simply call this again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodesNo
conversationNoProvenance for the saved pages: the source chat's title, date, and a one-line summary. Nothing else is stored. Never send the transcript.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
savedNo
titlesNo
nothingNo
refiledNo
skippedNo
chaptersNo
placementNo
remainingNo
savedCountNo
newChaptersNo
needsPlacementNo
placementUnknownNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false and idempotentHint=true; the description goes far beyond them, disclosing that saving REPLACES an existing page's body, that omitted sentences are deleted from the user's wiki, that an update body written from the conversation alone destroys the page, that duplicate saves are harmless because the server ignores them, and that it returns a receipt that may report pages that did not fit (requiring a re-call). That is the kind of consequence-level detail annotations cannot carry. Note the tension with destructiveHint=false, since the text describes body-replacing overwrites, but the description is the more informative source rather than a misstatement of the tool's identity.

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?

It is front-loaded with the trigger sentence and nearly every sentence carries actionable content (field rules, ordering, failure handling). However it is delivered as one dense block paragraph mixing usage, workflow, and per-field spec, which makes it harder to parse than a segmented layout would be; a few clauses ('Do not browse the whole wiki for this') could be tightened.

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

Completeness5/5

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

For a complex write tool with a 50%-covered schema, this description covers the full workflow (draft in full, resolve, read before update, save, show receipt, re-call if pages remain), the data contract, and the invariants. The return value is explained only as far as needed since an output schema exists, which is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% and the `nodes` items are schema-less, so the description has to compensate and does: it enumerates every required page field (`title`, `category_path`, `body_md`, `summary`, `links`, `quizzes`) with formatting rules (LaTeX, footnotes only for outside sources, 1-3 quizzes with option-length constraints), plus the top-level `conversation` block. This is substantially more semantic detail than the bare schema provides.

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 opens with a specific verb and resource ('save, file, keep... THIS conversation into their Eigma wiki') and immediately scopes what it produces (pages in the review inbox) and what it excludes (look-up trivia, logistics, small talk). It explicitly distinguishes itself from the sibling that handles existing pages: 'Editing pages that ALREADY exist is eigma_suggest_edits' job.' An agent can separate this tool from eigma_suggest_edits and eigma_resolve_pages without opening any schema.

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?

Usage is stated with explicit triggers ('when the user asks to save, file, keep, note, or remember THIS conversation'), explicit exclusions (nothing worth keeping yields no draft), a required prerequisite call (eigma_resolve_pages FIRST with every drafted page), a required follow-up call for updates (eigma_read_page), and a named alternative for other cases. When-to-use, when-not, and ordering are all covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources