Skip to main content
Glama
dreamforgestudiollc

EMET

by dreamforgestudiollc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

save_to_layer

Save memory to a specific layer with full control over metadata. PASS session_id - your transcript session from emet_session_open - on every save made inside a session: the server stamps derived_from with the exchange in progress.

Instructions

Save memory to a specific layer with full control over metadata. PASS session_id - your transcript session from emet_session_open - on every save made inside a session: the server stamps derived_from with the exchange in progress. Semantic and procedural entries are REFUSED without a source (session_id, or metadata.derived_from); nothing is written when refused.

Input Schema

NameRequiredDescriptionDefault
layerYesTarget memory layer
contentYesMemory content to save
exchangeNoThe exchange (turn) this write belongs to, counting from 1. A write for exchange n while exchange n-1 was never appended is refused by the session graph until n-1 is appended.
metadataNoFull metadata control
session_idNoYour transcript session id (from emet_session_open). The server reads that session's counter and stamps derived_from {session_id, exchange_start, exchange_end} with the exchange in progress. Ignored when metadata.derived_from is given. Required in practice for semantic and procedural saves made in a session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.5
    • changedInput schema / properties / metadata / properties / valid_until / description
      Previous value: -"Unix seconds. After this the entry stops surfacing in recall and queries (it is retained, never deleted). Meant for the working layer, whose entries are supposed to age out."New value: +"Unix seconds. After this the entry is marked ended and stays in recall and queries, with this date as its end date. It is not hidden and it is not deleted."
  2. Changed1 schema field changedv0.2.2
    • changedInput schema / properties / exchange / description
      Previous value: -"The exchange (turn) this write belongs to, counting from 1. A write for exchange n while exchange n-1 was never appended is flagged by the session graph."New value: +"The exchange (turn) this write belongs to, counting from 1. A write for exchange n while exchange n-1 was never appended is refused by the session graph until n-1 is appended."
  3. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish non-readOnly, non-destructive and non-idempotent. The description adds genuinely new behavior: the server auto-stamps derived_from from the in-progress exchange, semantic/procedural writes are refused without a source, and nothing is written on refusal. It omits what a successful write returns, but for a write tool with no output schema this is solid added context.

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?

Two sentences, purpose front-loaded before the operational caveats, with no filler. The all-caps emphasis (PASS, REFUSED) is slightly heavy but each sentence carries distinct, load-bearing information.

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 5-parameter, nested-object write tool this covers the main agent-facing risks: source attribution requirements, refusal behavior, and session stamping. Return values are undescribed and there is no output schema, but since the tool's observable outcome is whether the write succeeded or was refused, the description is effectively complete.

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?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining the runtime effect of session_id (reads the session counter and stamps derived_from) and its precedence over metadata.derived_from, plus the practical requirement that overrides the schema's optional-looking status.

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?

States a specific verb (save) and resource (memory layer) plus the distinguishing capability of full metadata control. It separates itself from query/recall siblings but does not explicitly contrast with the closely-named save_transcript, leaving that distinction to be inferred.

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?

Gives an explicit operational rule: pass session_id on every save made inside a session, and that semantic/procedural saves are refused without a reachable source. This is strong when-to-use guidance, though it never names an alternative tool (e.g. save_transcript) or states when not to use this tool.

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