Skip to main content
Glama
Pseudogiant-xr

PseudoLife-MCP

Official

memory_set_remove

Remove a specific member from a set-valued memory fact while preserving the audit trail. Use it to refine stored knowledge without erasing change history.

Instructions

Retract one current set member (audit row kept). Read with memory_fact_get.

Returns: {action, entity, attribute, member, members_count}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entityYesThe slot's subject.
memberYesThe current member to retract.
attributeYesThe slot's attribute.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.15.0
    • addedInput schema / properties / attribute / description
      Added value: +"The slot's attribute."
    • addedInput schema / properties / entity / description
      Added value: +"The slot's subject."
    • addedInput schema / properties / member / description
      Added value: +"The current member to retract."
  2. First observedv0.11.0

TDQS

A4/5.0
Behavior3/5

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

No annotations are present, so the description carries the full burden. It usefully discloses that an audit row is kept and that the return includes members_count, but it does not cover behavior when the member is absent, reversibility, or other edge cases.

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?

The description is compact and front-loaded: purpose, audit behavior, read-after hint, and return shape all appear in a few short lines with no filler or repetition.

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 simple three-parameter mutation with full schema coverage and a stated return shape, the description is nearly sufficient. A note on missing-member behavior or an example would make it fully complete, but nothing essential is missing for correct invocation.

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%, and each parameter already has a clear description such as 'The current member to retract' and 'The slot's attribute'. The tool description adds little parameter-specific meaning beyond the schema.

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 an active verb and resource: 'Retract one current set member', which precisely states what the tool does. It distinguishes itself from siblings like memory_set_add and memory_fact_set, and the parenthetical 'audit row kept' adds an important clarifying detail.

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?

The intended use is clear: removing an existing member from a set. The instruction 'Read with memory_fact_get' names the natural follow-up tool, but it does not explicitly state when not to use this tool or directly contrast it with memory_set_add.

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