Skip to main content
Glama

agent_forget

DestructiveIdempotent

Permanently delete a key from encrypted agent memory to retract obsolete or misremembered context. Destructive and irreversible.

Instructions

[agent] Permanently delete a single key from encrypted agent memory. Use to retract obsolete or misremembered context; prefer overwriting via agent_remember when you just want to update the value, and use delete_secret for actual credentials (which never live in agent memory). Destructive: there is no recycle bin. Returns 'Forgot "KEY"' on success or a not-found error if the key was already absent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesMemory key to delete.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.7
    • changedInput schema / properties / key / description
      Previous value: -"Memory key to forget"New value: +"Memory key to delete."
  2. Addedv0.11.5

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: there is no recycle bin, deletion is permanent, what the success string looks like, and that an already-absent key yields a not-found error rather than a silent success.

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?

Three sentences, front-loaded with the destructive action and its scope, then the routing guidance, then the return contract. Every clause earns its place; no filler.

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?

With no output schema, the description usefully documents the return contract ('Forgot "KEY"' / not-found error), and for a one-parameter destructive tool the combination of annotations plus the permanent/no-recycle-bin note is fully sufficient.

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 coverage is 100% for the single 'key' parameter, so the schema already carries the meaning. The description adds only 'from encrypted agent memory' as scope context, with no key-format or naming-convention guidance. Baseline 3 applies when the schema does the work.

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 ('Permanently delete a single key from encrypted agent memory') and explicitly distinguishes itself from the two most confusable siblings, agent_remember and delete_secret. An agent can route correctly 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 ('retract obsolete or misremembered context') and when-not-to-use, naming both alternatives with the condition that selects each (agent_remember for value updates, delete_secret for real credentials). Nothing is left to inference.

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