Skip to main content
Glama
aibtcdev
by aibtcdev

arxiv_compile_digest

Compiles a Markdown digest from recent arXiv papers on LLMs and autonomous agents, filtering by relevance score and grouping results by topic.

Instructions

Compile a Markdown digest from recent arXiv papers on LLMs and autonomous agents.

Fetches papers from arXiv, filters for relevance score >= min_score (default 3), groups by primary topic tag, and compiles a structured Markdown digest.

Digest structure:

  • Header with date, paper counts, and categories

  • Highlights section — top 5 papers by score

  • Per-topic sections (agent, multi-agent, LLM, tool-use, reasoning, RAG, etc.)

  • Stats table at the bottom

The compiled digest is returned inline as a Markdown string. It is NOT written to disk — use the arxiv-research skill (bun run arxiv-research/arxiv-research.ts compile) to write timestamped digest files to ~/.aibtc/arxiv-research/digests/.

Read-only. No API key required.

Tip: call earning_opportunities to see how to put your assets to work.

Input Schema

NameRequiredDescriptionDefault
dateNoDate label for digest header (YYYY-MM-DD). Default: today's date
min_scoreNoMinimum relevance score for digest inclusion. Default: 3
categoriesNoComma-separated arXiv category codes. Default: cs.AI,cs.CL,cs.LG,cs.MA
max_resultsNoMaximum papers to fetch. Default: 50

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.77.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries full behavioral burden and mostly delivers: it states read-only, no API key required, that papers are fetched from arXiv, filtered by minimum relevance score, grouped by topic, and returned inline as Markdown. It omits potential latency or failure behavior, but covers the essential non-obvious traits.

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?

The description is front-loaded with the core action, then organizes details into digest structure bullets and a file-writing alternative. Most sentences earn their place, though the trailing earning_opportunities tip is unrelated to the tool's function and slightly dilutes focus.

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 no output schema and no annotations, the description covers what the agent needs: the input-to-output transformation, the digest structure, that the result is an inline Markdown string, that no file is written, and that no API key is required. Nothing essential for correct invocation is missing.

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 parameters are already well documented in the schema. The description adds only marginal parameter context by mentioning the min_score default and grouping behavior; it does not expand on date, categories, or max_results beyond what the schema provides.

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 uses a specific verb ('Compile') and resource ('Markdown digest from recent arXiv papers on LLMs and autonomous agents'), then elaborates the fetch-filter-group-compile pipeline. It is clearly distinguishable from sibling tools like arxiv_search (searching papers) and arxiv_list_digests (listing existing digests).

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 clear context: use this tool to compile an inline digest, and use the arxiv-research skill instead when you need timestamped digest files written to disk. It does not explicitly contrast with arxiv_search, but the inline-vs-file distinction provides concrete alternative guidance.

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