Skip to main content
Glama
Sign In

Oxyo (oxyo.si) — Cut Coding Agent Token & Quota Burn by up to 72%

by io.github.Eno654
OverviewDiscussionsAdmin

oxyo_remember_episode

Append a timestamped task action, architectural decision, or observation to episodic history, returning the stored episode metadata. Use for chronological event logs; use oxyo_remember_belief instead for standing rules or facts.

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": {
      "content": "<content>"
    },
    "name": "oxyo_remember_episode"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoEvent category ('action' for changes made, 'observation' for findings, 'user' for requests).observation
scopeNoProject/repo scope where this episode applies (defaults to 'global').
contentYesConcise summary of the completed action, decision, or technical observation.
importanceNoBase retention priority score between 0.0 (trivial) and 1.0 (critical milestone).
use_neural_salienceNoAutomatically calibrate retention priority based on novelty and information density.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / content / description
      Added value: +"Concise summary of the completed action, decision, or technical observation."
    • addedInput schema / properties / importance / description
      Added value: +"Base retention priority score between 0.0 (trivial) and 1.0 (critical milestone)."
    • addedInput schema / properties / kind / description
      Added value: +"Event category ('action' for changes made, 'observation' for findings, 'user' for requests)."
    • changedInput schema / properties / scope / description
      Previous value: -"Optional project/repo scope (default 'global')"New value: +"Project/repo scope where this episode applies (defaults to 'global')."
    • addedInput schema / properties / use_neural_salience / description
      Added value: +"Automatically calibrate retention priority based on novelty and information density."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the description needn't re-establish the safety profile. It still adds real value beyond them: append-only/immutable-history semantics, automatic timestamping, and the fact that stored episode metadata is returned. It stops short of noting that repeated identical calls create duplicate episodes (non-idempotent), which would have been the last useful detail.

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

Conciseness5/5

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

Two sentences, no filler. The primary behavior and return value come first, and the sibling routing rule follows immediately, so the most decision-relevant information is front-loaded.

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?

With no output schema, the description correctly compensates by stating that stored episode metadata is returned, and the fully-described schema covers all parameters. For a simple single-write append tool this is nearly complete; only the duplicate-append consequence of non-idempotency is left implicit.

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

Parameters3/5

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

Schema description coverage is 100%, so all five parameters including the `kind` enum and the `importance`/`use_neural_salience` pair are already documented. The description's mention of action/decision/observation loosely maps to the `kind` enum but adds no syntax, defaults, or interaction details beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ('Append ... to episodic history'), enumerates the content types it accepts, and explicitly contrasts itself with `oxyo_remember_belief` for standing rules. An agent can distinguish this from the belief/recall siblings 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?

Gives explicit when-to-use guidance ('chronological event logs') and names the alternative tool plus the condition that selects it ('standing rules or facts'). No inference is required to route between the two.

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

All Oxyo (oxyo.si) — Cut Coding Agent Token & Quota Burn by up to 72% toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources