Skip to main content
Glama
Sign In
linklore

linklore

Official
by linklore
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

rm

Delete lore/doc, sent messages, members, or entire openboxes. Supports recoverable trash, permanent force, batch operations, and explicit action selection.

Instructions

rm — unified delete. Target is chosen by argument (action= is an explicit alternative, auto-detected by which argument is present when omitted).

Deleting items (lore/doc) — id is a single value or a list (batch)

  • trash (recoverable, default) → rm(id) → restore(id) to recover

  • permanent delete (unrecoverable) → rm(id, force=True)

  • batch delete → rm(id=['lr-x','dc-y'], force=True)

  • mark as dropped (stays in search) → edit(id, status='dropped')

  • supersede (keep old + new head) → add(type='lore'|'doc', relates=old_id, ...)

Taking down something you sent (reverse of push/send, doesn't touch the source of truth)

  • rm(sent='lr-x'|'dc-x', openbox='ai-team') take down from an openbox (sender only)

  • rm(sent='lr-x'|'dc-x') take down from my server

  • (or action='sent', sent= is still required — action= is just the explicit form)

Removing a member (openbox owner only)

  • rm(member='<member_id>', openbox='ai-team') (or action='member')

Deleting an entire openbox (shared space) (owner, unrecoverable → always asks to confirm)

  • rm(openbox='ai-team') 1st call: returns a warning+question (nothing executes)

  • rm(openbox='ai-team') identical 2nd call → that itself is the confirmation, actually deletes (no confirm= param)

  • (space= is an alias for openbox=)

  • (or action='openbox', openbox= is still required)

  • ⚠️ action='openbox' cannot combine with id= (explicit rejection) — deleting an item and deleting an entire shared space are separate operations. id alone (action unspecified) goes to regular item delete.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "rm"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNo
helpNo
sentNo
forceNo
spaceNo
actionNo
memberNo
openboxNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

No annotations provided, so description carries full burden. It discloses recoverability of trash, unrecoverability of permanent delete, confirmation flow for openbox deletion, auto-detection of action, and that action='openbox' cannot combine with id=. No contradictions.

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?

Well-structured with headings and bullet points, front-loaded with core purpose. However, somewhat verbose; could be trimmed slightly without losing essential information.

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?

Given the high complexity (8 parameters, multiple operations) and lack of annotations, the description addresses all relevant aspects: use cases, parameter roles, behavioral nuances, and alternatives. Output schema likely covers return values, so omission is acceptable.

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

Parameters5/5

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

Schema coverage is 0%, but description thoroughly explains all parameters: id (string or list for batch), force (permanent delete), sent (take down), member (remove member), openbox/space (space alias), action (explicit alternative, auto-detected when omitted), help (likely debug). Adds meaning beyond schema titles.

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 clearly states 'rm — unified delete' and explains multiple deletion contexts (items, sent items, members, openboxes). It distinguishes from sibling tools like edit, add, and restore by specifying when to use those instead.

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?

Provides explicit guidance for each scenario: trash vs permanent delete via force flag, batch delete with list, mark as dropped via edit, supersede via add, take down with sent and openbox parameters, remove member, and delete openbox with two-call confirmation. Also warns against combining action='openbox' with id=.

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