Lion Reader

remove_from_collection

DestructiveIdempotent

Remove articles from a collection without deleting them: they stay in their feeds and in Saved (to delete a saved article, use delete_saved_article; to delete the whole collection, delete_collection). Their positions in the collection are lost. Returns the IDs actually removed; IDs not in the collection are skipped. Fails with a not-found error if the collection isn't the user's.

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": {
      "collectionId": "<collectionId>",
      "entryIds": "<entryIds>"
    },
    "name": "remove_from_collection"
  }
}

Input Schema

Name	Required	Description	Default
`entryIds`	Yes	Entry IDs
`collectionId`	Yes	The collection's subscription ID (list_subscriptions shows collections with type 'collection')

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Goes well beyond the destructiveHint/idempotentHint annotations: it discloses that entries persist in feeds and Saved, that ordering positions are lost, that partial results are returned with non-members silently skipped, and the exact not-found failure mode for foreign collections. The only gap is that the 1000-item cap and batch behavior aren't mentioned in the prose, though the schema carries maxItems.

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 tight sentences, front-loaded with the core distinction and followed by consequences, return contract, and failure mode. Every clause carries information an agent needs; 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?

There is no output schema, yet the description explains the return value ('IDs actually removed', skipped IDs) and the error contract, which is exactly what would otherwise be missing. For a two-parameter destructive mutation with full annotation coverage, nothing material is absent.

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% with per-field descriptions, so baseline is 3, but the description adds real semantics: entryIds not present in the collection are skipped rather than erroring, and the returned set reflects only actually-removed IDs. collectionId ownership semantics are also clarified via the not-found failure condition.

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 ('Remove articles from a collection') and immediately disambiguates it from deletion ('without deleting them'). An agent can distinguish this from delete_collection and delete_saved_article 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?

Explicitly names two alternatives with their selecting conditions: use delete_saved_article to delete a saved article, delete_collection to delete the whole collection. It also states the boundary condition where this tool fails (collection not owned by user). Nothing about when-to-use 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.

All Lion Reader tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.