Skip to main content
Glama
blazickjp

ArXiv MCP Server

by blazickjp
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

watch_topic

Create or update a persistent arXiv paper alert. Poll check_alerts to receive only new papers matching your query since the last check.

Instructions

Save or update a persistent research topic watch. When checked via check_alerts, returns only papers published since the last check — acting as a standing alert for new work on a topic. New watches seed last_checked to creation time so the first check does not dump historical matches. The topic string uses the same query syntax as search_papers (quoted phrases, field specifiers, boolean operators). Examples: '"diffusion models" AND ti:"video generation"', 'au:"LeCun" AND cs.LG'. Calling watch_topic with the same topic string updates the existing watch rather than creating a duplicate. On update, omit categories to preserve existing filters; pass categories: [] to clear them. Pair with check_alerts to poll for new papers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicYesQuery string to monitor. Uses arXiv search syntax — quoted phrases for exact matches, field specifiers (ti:, au:, abs:), and boolean operators (AND, OR, ANDNOT). Example: '"reinforcement learning" AND "robotics"'.
categoriesNoOptional arXiv category filter (e.g. ['cs.LG', 'cs.AI']). Narrows results to specific fields. On update, omit this field to preserve existing categories; pass an empty array [] to clear them.
max_resultsNoMaximum papers to return per alert check (default: 10).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.2
    • changedInput schema / properties / categories / description
      Previous value: -"Optional arXiv category filter (e.g. ['cs.LG', 'cs.AI']). Narrows results to specific fields."New value: +"Optional arXiv category filter (e.g. ['cs.LG', 'cs.AI']). Narrows results to specific fields. On update, omit this field to preserve existing categories; pass an empty array [] to clear them."
  2. Addedv0.6.1

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining the mutation profile — and it does so richly. It discloses the last_checked seeding side-effect ('first check does not dump historical matches'), the upsert semantics, and the subtle update behavior for categories ('omit categories to preserve existing filters; pass categories: [] to clear them'). This goes well beyond what annotations provide and flags exactly the behaviors an agent could not infer from the schema alone.

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?

Seven sentences, and every one earns its place: purpose, check_alerts behavior, first-check seeding, query syntax, upsert semantics, category-update gotcha, and integration pairing. The most decision-relevant information is front-loaded, and the length is justified by the tool's genuinely subtle stateful semantics. There is zero 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 stateful tool with no output schema and only three boolean annotations, the description covers nearly everything an agent needs: lifecycle behavior, first-run nuance, update semantics, query syntax, and the companion tool. The only notable gap is that it describes what check_alerts returns but never states what watch_topic itself returns on success (acknowledgment, watch object, etc.), which the absence of an output schema makes more consequential.

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%, so the baseline is 3; the schema already documents topic syntax, category update semantics, and max_results default. The description adds some value by providing two concrete query examples with field specifiers and boolean operators, and it reinforces the categories-preservation rule. But it largely restates what the schema already says and adds nothing new about max_results, so it does not rise above the baseline.

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 opening verb-resource pair 'Save or update a persistent research topic watch' is specific and precise, and the tool's role is further differentiated from siblings by explaining it 'returns only papers published since the last check' when polled via check_alerts. It also distinguishes itself from search_papers by noting the shared query syntax while making clear this is a persistent standing alert, not a one-off search. The upsert behavior ('same topic string updates the existing watch rather than creating a duplicate') removes any ambiguity about what calling this tool does.

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 description gives explicit integration context ('Pair with check_alerts to poll for new papers') and explains when the tool behaves differently on first use versus updates, which helps the agent choose correctly. It references search_papers for query syntax, implicitly distinguishing one-off searches from standing alerts. However, it never explicitly states 'use search_papers instead for a one-off search' or names when NOT to use watch_topic, so the exclusion logic is left slightly to inference.

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

Install Server

Other Tools