Skip to main content
Glama
Sign In
mcp-arxiv-research-server

mcp-arxiv-research-server

by jafarSalim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Remove from reading list

library_remove
DestructiveIdempotent

Remove a paper from the local reading list by ID, keeping your saved arXiv library organized and current.

Instructions

Remove a paper from the local reading list.

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": {
      "id": "<id>"
    },
    "name": "library_remove"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3/5.0
Behavior3/5

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

The annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful scoping fact that this only touches the 'local reading list', but it says nothing about behavior when the paper is absent or what else is discarded, which matters for a destructive operation.

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?

One short sentence with the action and target front-loaded, and no wasted words. It is efficient but borders on under-specification rather than being trimmed for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-output tool with full annotation coverage, the definition is minimally adequate. Still missing are the id's expected form and the outcome when the paper is not on the list, both of which an agent would want before calling a destructive tool.

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

Parameters2/5

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

There is a single required 'id' parameter with 0% schema description coverage, so the description carries the burden. Saying it removes 'a paper' hints that the id identifies a paper, but it never clarifies whether that is a local reading-list entry id or an external paper identifier, leaving meaningful ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description pairs a specific verb ('Remove') with a specific resource ('a paper from the local reading list'), so its effect is unambiguous and it is naturally distinguished from library_add and library_list. It stops short of explicitly naming a sibling to contrast with, which keeps it out of 5 territory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use/when-not guidance and no mention of alternatives such as library_add or library_list. The word 'local' weakly implies scope (local storage only, not remote services), but an agent must infer that pruning the reading list is the intended use case.

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