arXiv MCP Server

Tool Scores

• get_statsA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It successfully discloses the output structure (what statistics are returned), but omits critical behavioral traits such as confirming read-only safety, performance characteristics, or caching behavior that would help an agent understand execution impact.

  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?

  Two well-structured sentences with zero waste. The first sentence front-loads the core purpose, while the second efficiently summarizes the return payload. Every word earns its place.

  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?

  Adequately complete for a zero-parameter aggregation tool. Given the existence of an output schema, the description appropriately summarizes rather than duplicates return value specifications. Minor gap: could explicitly confirm this is for aggregate overview vs. individual record inspection.

  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?

  Tool accepts zero parameters, establishing a baseline of 4. The description appropriately omits parameter discussion as there are no inputs to clarify, matching the empty input schema without contradiction or redundancy.

  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?

  Provides a specific verb ('Get') and resource ('statistics about papers') with clear scope ('local database'). The enumeration of return values (total count, date range, per-date breakdown, top categories) effectively distinguishes this from siblings like count_papers_on_date and query_papers, though it does not explicitly name those alternatives.

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

  Usage Guidelines3/5

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

  Offers implied usage guidance through the detailed description of return values (e.g., comprehensive stats vs. single-date counts), but lacks explicit 'when-to-use' directives or comparisons against siblings like count_papers_on_date or query_papers.

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

• cleanup_papersA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Discloses: destructive nature, safety guardrails (requires ≥1 filter), AND logic between filter types, OR logic within categories, and exclusive date boundary. Could further clarify permanence/irreversibility of deletion.

  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 safety constraint front-loaded. Main clause establishes operation, followed by constraint, logic explanation, and Args section with examples. Slightly verbose Args section necessary given zero schema coverage.

  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?

  Appropriate for complexity: covers safety critical for destructive tool, explains parameter interactions (AND/OR), and output schema exists so return values need no description. Missing explicit note that deletion is permanent/irreversible.

  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 has 0% description coverage (only titles). Description fully compensates by providing semantic meaning, format examples ('2026-03-01'), and logic constraints (exclusive, specific, OR logic) for all 3 parameters.

  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?

  Specific verb 'Delete' + resource 'papers' + scope 'local database' + mechanism 'by date and/or category'. Implicitly distinguishes from read-only siblings (fetch_papers, query_papers, count_papers) through explicit destructive language.

  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?

  Excellent safety constraint: 'At least one filter must be provided to prevent accidental full deletion.' Explains filter logic (AND between fields). Missing explicit reference to sibling query_papers for previewing deletions, but includes critical guardrails.

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

• fetch_papersA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, description carries full burden. It successfully discloses: (1) persistence side-effect ('store them in local database'), (2) limited return format ('Returns only fetched paper titles'), and (3) external API dependency ('arXiv API'). Missing minor details like rate limits or duplicate handling, but covers major behavioral 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?

  Well-structured with 3 front-loaded prose sentences covering purpose, output, and alternatives, followed by Args section. Given 0% schema coverage, the Args block is necessary and earns its place. Slight verbosity from redundant 'Args:' header but acceptable given constraints.

  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?

  Appropriate for a 4-parameter tool with output schema: description clarifies the storage mutation and return limitation without needing to replicate output schema details. Workflow guidance covers the gap between fetch_papers and query_papers.

  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 description coverage is 0%, requiring description to compensate completely. The Args section documents all 4 parameters with rich semantics: category includes examples ('cs.AI'), date includes format (YYYY-MM-DD) and priority logic ('takes priority over'), num_days includes default (3) and interaction ('Ignored when date is set').

  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?

  Excellent specificity: verb 'Fetch', resource 'papers from arXiv API', scope 'recent', and critical side-effect 'store them in the local database'. Effectively distinguishes from sibling query_papers by noting this tool stores to database while query_papers retrieves specific fields.

  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 alternative tool with specific syntax: 'Use query_papers(entry_ids=[...], fields=["abstract"]) to retrieve abstracts'. This provides clear workflow guidance (fetch first, then query) and indicates when to use the sibling instead.

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

• query_papersA
  4.6/5.0
  Behavior4/5

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

  Excellent disclosure of query semantics: explains default behavior when no filters provided (returns most recent), documents the logical operators used, and details parameter interaction effects. As annotations are absent, this carries the full behavioral burden well, though explicit 'read-only' statement is absent.

  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?

  Structure is exemplary: single-sentence purpose statement upfront, followed by logic explanation, then organized Args block. No filler text; every line conveys specific constraints or behaviors. Docstring-style formatting is readable and efficient.

  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?

  Fully complete for a query tool of this complexity. All 6 optional parameters are documented, filter logic is explained, and since an output schema exists (per context signals), return values need not be described in narrative.

  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?

  With 0% schema description coverage, the Args section compensates perfectly by providing detailed semantics for all 6 parameters: date format with example, category logic with examples, field selection with valid values and defaults, and specific usage notes for entry_ids.

  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?

  Opens with specific verb ('Query'), resource ('papers'), and scope ('local database'), clearly distinguishing from siblings like 'fetch_papers' (external) and 'count_papers_on_date' (aggregation). The phrase 'flexible filtering and field selection' further clarifies capabilities.

  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?

  Provides clear behavioral guidance on filter logic (AND between parameters, OR within categories) and warns that 'entry_ids' is typically used alone with caveats about combining filters. Lacks explicit comparison to sibling tools like 'fetch_papers'.

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

• count_papers_on_dateA
  4.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It implies this is a safe read operation (counting) and clarifies its role in the workflow chain. However, it doesn't explicitly state error conditions, rate limits, or the exact return type (though output schema exists to cover the latter).

  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?

  Front-loaded with purpose statement, followed by usage context, then structured Args documentation. Every sentence earns its place; no tautology or repetition of the tool name. Appropriate length for the complexity.

  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 2 simple flat parameters and the existence of an output schema (mentioned in context signals), the description is complete. It covers purpose, usage sequencing, and parameter semantics without gaps.

  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?

  Critical compensation for 0% schema description coverage. The Args section adds essential semantics: category includes valid arXiv examples (cs.AI, cs.CL, stat.ML) and date specifies YYYY-MM-DD format with a clear example—information completely absent from the raw schema.

  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 opens with a specific verb (Count) + resource (papers) + precise scope scope (arXiv category on specific date). It clearly distinguishes from sibling fetch_papers by emphasizing this only returns a count, not the papers themselves.

  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 prescribes when to use ('before fetch_papers') and why ('to check the volume... so you can decide how many to fetch'). Names the sibling alternative directly and establishes the workflow dependency clearly.

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