Skip to main content
Glama
dreamforgestudiollc

EMET

by dreamforgestudiollc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

save_to_layer

Save memory to a specific layer with full metadata control; include session_id or derived_from so semantic and procedural entries are accepted with verifiable provenance.

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

TableJSON 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.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."
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds substantial behavior beyond that: the server stamps derived_from with the in-progress exchange, semantic/procedural entries are REFUSED without a source, and nothing is written when refused. That refusal atomicity is exactly the kind of consequence an agent must know before calling.

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?

The purpose is front-loaded in the first clause, followed by the critical session_id directive and the refusal consequence. Three dense sentences, all earning their place, though the emphasis-shift to the refusal rule makes it slightly less cleanly ordered.

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 mutation tool with no output schema but full annotation coverage, the description supplies the key behavioral facts an agent needs: source requirement, refusal semantics, and derived_from stamping. Remaining gaps (return shape, interaction with revise_memory) are minor given the annotations and detailed 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?

Schema coverage is 100%, so the baseline is 3; the description earns a bump by tying session_id to a concrete outcome (derived_from is stamped) and to the refusal rule, reinforcing the interaction between session_id and metadata.derived_from. It does not add format detail beyond the already-rich schema.

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 and resource ('save memory to a specific layer') with an explicit scope ('full control over metadata'), which is clearly distinct from siblings like save_transcript or revise_memory. It does not name an alternative directly, so it lands at a strong 4 rather than a 5.

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 semantic/procedural entries are refused without a source. This is clear usage context, but it never contrasts with sibling tools or states when to prefer this over revise_memory, so it stops short of 5.

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