paperboy

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation5/5
Each tool targets a distinct operation: filing, listing collections, listing queue, queuing, recommending, removing, searching, sending individual papers, sending full queue, and status. No functional overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., queue_papers, search_papers, setup_status), making them predictable and easy to understand.
Tool Count5/5
10 tools is well-scoped for a paper management server, covering essential operations without bloat. Each tool serves a clear purpose in the reading queue workflow.
Completeness4/5
The tool surface covers all major operations: add, remove, search, recommend, send (individual and batch), file into collections, list state, and check setup. Minor gap: no ability to edit collection names or delete collections, but core lifecycle is complete.
Average 4.6/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 75 commits in the last 12 weeks
- Last stable release on July 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the download from URL/local path, creation of Zotero item from supplied metadata, PDF attachment, on-demand collection creation, and optional send-to-reader. It does not detail duplicate handling or error behavior, but covers core behavioral traits adequately.
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 main action and is structured logically. Each sentence adds value, but it is somewhat dense and could be more concise by grouping related info. Still, it avoids wasted words.
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?
The description covers the tool's purpose, input expectations, and behavior well. With an output schema present, return values need not be explained. It mentions the prerequisite 'Requires Zotero' and contrasts with queue_papers. Minor gaps remain regarding error conditions and idempotency, but overall it is sufficiently complete.
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 0%, so description must compensate. It adds context for item_type (lists valid values), send (delivers to e-reader), collections (created on demand), and url_or_path (explains http(s) or local). However, it omits doi and year parameters entirely, and does not systematically describe each field.
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 clearly states the tool ingests a PDF into Zotero with attachment, specifies it's for grey literature, and distinguishes itself from sibling tool queue_papers by noting it does not queue. The verb 'ingest' and resource 'PDF into Zotero' are specific and actionable.
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 provides explicit use cases (grey literature, no registry indexes) and contrasts with queue_papers. It also mentions using 'book' item type for open-access textbooks. However, it does not explicitly exclude other sibling tools like add_book or list alternative scenarios, so some guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as authentication needs, rate limits, error cases, or side effects beyond listing. The description is minimal on behavioral details.
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?
Two sentences, front-loaded with core function. The second sentence is detailed but earned, providing critical usage guidance. Could be slightly shorter, but effective.
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?
Given zero parameters and an output schema, the description covers the essential purpose and usage context. It lacks details on output format or edge cases, but the output schema fills that gap. Overall fairly complete for a simple listing tool.
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?
No parameters exist, so schema coverage is 100% trivially. The description adds no parameter-specific information but provides valuable usage context. Baseline for 0 parameters is 4.
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 clearly states the tool lists Zotero collections with specific fields (name, item count, parent), and it distinguishes from siblings like list_queue and search_papers by its specific resource and context.
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 says to use this before queueing or sending new papers, provides clear decision logic for passing collections or asking the user, and contrasts with silent guessing. This strongly guides when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses source fallback behavior, max_results clamping, output fields (ref, open_access_pdf), and notes potential delivery failures for OA links. Lacks rate limits or permissions, but covers key behaviors.
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 concise and front-loaded with purpose. Each sentence adds value, though the structure could be slightly improved by separating parameter explanations more cleanly.
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?
Given the presence of output schema, the description adequately covers parameter semantics and output expectations. It does not mention error handling or empty results, but overall provides sufficient context for a search tool.
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 description fully compensates by explaining the source options and behavior, max_results clamping range, and the meaning of output fields. The query parameter is self-explanatory.
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 clearly states it searches for papers across scholarly literature. While it does not explicitly contrast with sibling tools, the purpose is specific and well-defined.
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 provides guidance on when to use 'all' vs 'arxiv' source, including trade-offs. It does not explicitly state when to use this tool over siblings, but the distinct operation (search vs. file/queue/send) is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool blends two signals, excludes papers already in the user's library (queue + 100 most recent), caps max_results at 20, and returns picks with a 'via' field and a problems array. It also notes that interests lead results and that problems should be relayed. It does not mention any destructive side effects or authentication requirements, but the tool appears to be read-only, so this is acceptable.
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 well-structured with a clear opening sentence, then explains the signals, parameters, output format, and important usage notes. It is front-loaded with purpose. While slightly verbose, each sentence adds value and no information is redundant. A minor improvement could be tighter phrasing.
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?
Given no annotations and zero schema coverage, the description provides a comprehensive overview: it explains the two discovery arms, the output format (picks and problems), the 'via' field semantics, and the exclusion of library papers. It also mentions an upstream limit (computer science only). It lacks information about error states (e.g., if all seeds fail) or rate limits, but for a recommendation tool it is reasonably complete.
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?
The input schema has 0% description coverage, so the description must compensate. It explains each parameter: interests (2-4 short phrases), seed_refs (for citation graph seeding), max_results (capped at 20), and recent_only (new vs all-time). It also clarifies defaults (uses library if no interests) and constraints (computer science only upstream). This adds meaningful context beyond 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 clearly identifies the tool as discovering papers the user may want to read, blending citation-graph and keyword signals. It specifies sources (Semantic Scholar, OpenAlex) and states that it excludes already-in-library papers. This distinguishes it from sibling tools like search_papers (which likely returns exact matches) and queue/send operations.
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 explains when to use the tool (to get paper recommendations) and how to provide inputs (interests as phrases, seed_refs for explicit seeds). It also advises to present picks and let the user choose, not send unasked. However, it does not explicitly state when not to use it, e.g., if the user wants a simple keyword search rather than a blended recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key traits: collection creation on demand (only if papers match), items stay in queue, delivery state unaffected, and matching method. Missing details on error handling or authentication, but overall transparent.
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?
Six sentences with no wasted words. The main purpose is front-loaded, and every sentence adds essential information (prerequisite, alternative, side effects, matching behavior). Very concise.
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?
Given the two-parameter tool and presence of an output schema, the description covers prerequisites, side effects, matching, and edge cases (empty collection not created). It is nearly complete; the output structure is covered by the output schema.
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 0%, so description must add meaning. It explains that 'refs' uses exact matching (arXiv id, DOI, URL, title) and implies 'collection' is a name. The description adds value beyond the schema, though collection format is not detailed.
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 clearly states the verb 'file' and resource 'already-queued papers into a Zotero collection', and it distinguishes from siblings like queue_papers (which queues) and unfile_papers (implied inverse). The matching method and prerequisite are explicit.
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?
The description explicitly states when to use (only for papers already in the queue), when not to (for fresh papers, use queue_papers), and provides an alternative (pass collections to queue_papers). Also covers the condition that collection creation only occurs if papers match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It details deduplication, skipping already-sent papers, auto-splitting batches, handling of open-access PDFs, Zotero integration, and dry_run behavior. This is comprehensive for a mutation tool.
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 well-structured and front-loaded with the main purpose. Each sentence adds value, covering edge cases and behaviors. It could be slightly more concise, but it remains informative without unnecessary repetition.
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 the tool's complexity (4 parameters, output schema exists), the description is complete. It covers input formats, behaviors, side effects, error handling, and expected output (receipt). The existing output schema obviates the need to describe return values.
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 0%, so the description fully compensates. It explains the accepted formats for refs, the effect of force, dry_run, and the optionality of collections. While it doesn't restate defaults, it adds practical context beyond the 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 clearly states the tool sends papers to an e-reader by arXiv id, DOI, or title. It uses specific verbs ('send') and resources ('papers'), and distinguishes from siblings like 'file_papers' and 'send_queue' which have different actions.
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 provides guidance on when to use the tool, including using dry_run for previews, checking list_collections for placement, and noting limitations like no duplicate protection without Zotero. It lacks explicit 'when not to use' but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses key behaviors: non-destructive addition, duplicate avoidance, optional collection creation on demand, and reporting of unresolvable papers. All behavioral traits are covered.
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?
The description is concise (five sentences), front-loaded with the main purpose, and efficiently provides all necessary details without redundancy. Every sentence adds value.
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 the tool's complexity (multiple input types, optional collections, error handling), the description is complete. It covers all aspects an agent needs to know: input, behavior, edge cases, and interaction instructions.
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?
With 0% schema description coverage, the description compensates well by explaining that 'refs' accepts various identifiers and that 'collections' is optional for filing papers, including guidance to use list_collections. Adds significant meaning beyond 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 clearly states the tool adds papers to the Zotero Reading Queue without sending them. It specifies accepted input types and distinguishes from siblings by mentioning it does not send, contrasting with send_papers.
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 explicit guidance on accepted inputs (arXiv ids, DOIs, URLs, titles), duplicate handling, optional collections, and error reporting. Instructs to check list_collections when placement is unclear, but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description fully discloses behavioral traits: items filed elsewhere keep their library record, items without other collections move to Trash (restorable ~30 days), trashed items no longer count for duplicate protection, and nothing is permanently deleted from Zotero or the e-reader. This richly supplements the bare schema.
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 efficiently structured with a clear lead sentence followed by bullet-like paragraphs. Every sentence serves a purpose (behavioral details, edge cases, user guidance), but the flow could be tightened slightly (e.g., merging duplicate-handling into a single sentence) without losing clarity.
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?
Despite the simple single-parameter schema, the tool has complex side effects (trashing, collection membership, duplicate protection). The description covers all these scenarios, including behavior on duplicate matches and instructions for user interaction. An output schema exists, so return value explanation is unnecessary.
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?
The input schema only defines 'refs' as an array of strings without descriptions. The tool description compensates by specifying acceptable formats (arXiv id, DOI, URL, exact title) and explains matching behavior, uniqueness constraints, and the need for disambiguation—adding essential semantic value beyond the 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 'Remove papers from the Zotero Reading Queue by ref or title', a specific verb-resource pair that clearly distinguishes this tool from siblings like list_queue (listing), queue_papers (adding), and send_queue (sending). It leaves no ambiguity about the core function.
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 provides a clear context for use (removing items from the queue) and explains behavior on duplicate matches, but it does not explicitly list when this tool should be avoided or name direct alternatives. The guidance within (e.g., 'Relay the choice to the user — never pick for them') adds operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: the tool never adds to the Reading Queue, never sends, treats no-OA-PDF papers as normal library records (no 'no-oa-pdf' tag), reports duplicates with existing collections, and creates collections on demand.
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 well-structured with a clear opening statement, a contrast to siblings, and detailed behavioral notes. Every sentence adds value, but it is slightly lengthy; a more concise version could be trimmed without losing essential information.
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 the low complexity (2 parameters, no enums) and presence of an output schema, the description is comprehensive. It covers purpose, usage context, parameter semantics, behavioral quirks (duplicates, no-OA handling), and error handling (unresolvable refs).
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 description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'refs' can be 'arXiv id, DOI, URL, or title' and that 'collections' are optional and 'created on demand'. This provides significant context beyond the raw schema, though a bit more detail on parameter formats would be ideal.
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 clearly specifies the tool's action: 'Track papers in Zotero WITHOUT staging them for e-reader delivery.' It identifies the resource (papers in Zotero/library) and distinguishes itself from the sibling tool queue_papers by explicitly stating the 'just catalogue it' path.
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?
The description provides explicit guidance on when to use this tool ('for references you want to keep ... rather than deliver') and contrasts with an alternative (queue_papers). It also instructs the agent to relay unresolvable refs to the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently discloses that only membership in the named collection is dropped, while other collections and sent-state remain untouched. It also explains the behavior for ambiguous refs (removes nothing).
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 fairly concise for the amount of detail, but it could be slightly shorter. The key action is front-loaded, and additional context is provided in subsequent sentences. The structure is logical but includes some extra detail that might be condensed.
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 annotations and partial schema, the description covers purpose, usage guidelines, behavioral details, parameter semantics, and edge cases (e.g., ambiguous refs, refusal of Reading Queue). It is complete enough for an AI agent to correctly select and invoke the tool.
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?
The input schema defines refs (array of strings) and collection (string) with 0% coverage. The description adds meaning by explaining that refs match exact arXiv id, DOI, URL, or title, and that collection is the target collection. This compensates for the schema's lack of description, though more detail on collection identification would be helpful.
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 clearly states the tool removes papers from one Zotero collection, using the verb 'Remove' and specifying the resource 'papers from one Zotero collection'. It distinguishes itself from siblings like file_papers and remove_from_queue by highlighting its inverse nature and specific scope.
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?
The description explicitly explains when to use the tool (for misfiled items) and when not (Reading Queue is refused as a target, with a pointer to remove_from_queue for that purpose). It also provides instructions for moving papers between collections and clarifies ambiguous ref handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses behavioral traits: statuses ('unsent', 'sent', 'no-open-access-pdf'), key uniqueness for duplicates, and UTC dates. It fully covers what the tool returns and its read-only nature.
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?
Four sentences, each earning its place. First sentence states purpose, second lists statuses, third gives usage and key details, fourth mentions dates. No waste.
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 params and an output schema (not shown), the description sufficiently explains return fields and behavior. It covers purpose, usage, statuses, keys, and dates, making it complete for a listing tool.
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?
No parameters exist, so schema coverage is irrelevant. Description adds no parameter info, but baseline is 4 since there are no parameters to describe.
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 explicitly states it lists the reading queue with delivery status per item. It distinguishes from siblings by mentioning usage before send_queue and for remove_from_queue, and highlights unique key and date 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?
It provides explicit guidance: 'Use this to show the user their queue, before send_queue ... or to find refs for remove_from_queue.' This tells when to use this tool versus alternatives like send_queue or remove_from_queue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses critical behaviors: skipped tags (sent, no-oa-pdf), auto-tagging of unavailable PDFs to prevent retries, and automatic batch splitting under email limits. This fully informs the agent of side effects and constraints.
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?
Very concise: main action in first sentence, followed by essential behavioral details and sibling reference. Every sentence adds value with no redundancy.
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 parameters and presence of output schema (implied), the description covers all necessary aspects: action, scope, exclusions, side effects, and alternative tool. It is fully sufficient for an agent to use correctly.
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?
Input schema has zero parameters, so description need not explain them. Baseline 4 applies since schema coverage is trivially 100% and no parameter details are required.
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 starts with a specific verb and resource: 'Send EVERY unsent paper in the Zotero Reading Queue.' It distinguishes from sibling tool send_papers by stating 'for specific papers use send_papers,' making the tool's scope clear.
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 states when to use ('flush the whole queue') and when not to ('for specific papers use send_papers'). Also advises checking list_queue first when unsure, providing clear guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses that the tool 'Returns configuration state only — never secret values,' a critical behavioral trait for a status-checking tool, ensuring the agent knows it is safe and read-only.
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?
The description consists of three concise sentences. The first sentence front-loads the primary purpose. Every sentence adds unique value without redundancy.
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 the output schema exists (not shown but indicated), the description provides sufficient context: what it returns, how to use it, and security guidance. It is complete for a simple status-check tool.
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?
The tool has no parameters (schema coverage 100% trivially). The description does not add parameter-specific detail (none needed), but it clarifies the tool's purpose, which helps an agent understand no input is required. Given the baseline of 4 for zero parameters, this is appropriate.
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 the verb 'Report' and specifies the resource: 'which paperboy features are configured and what's missing.' This clearly distinguishes it from sibling tools that deal with papers, collections, or queue management.
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 states when to use: 'Use this to guide the user through finishing setup.' Also provides clear guidance on what not to do: 'Credentials themselves must be entered by running 'paperboy setup' in a terminal, never pasted into the chat.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral traits: it resolves identifiers into a proper Zotero book item, does not queue/deliver, creates collections on demand, deduplicates by ISBN, and returns closest candidate for loose matches. It warns about corrupting citations.
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?
The description is efficient; each sentence adds value. It is front-loaded with the purpose and structured logically: input methods, output type, exclusions, parameter usage, and dedup behavior.
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 the tool's complexity (2 params, no annotations, but output schema present), the description covers input, behavior, error handling, dedup, and relationships to other tools. The output schema handles return values, so completeness is high.
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%, but the description adds rich meaning: identifier can be ISBN-10/13, book DOI, or title; collections are for filing topically and created on demand. This fully compensates for the missing schema descriptions.
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 starts with a specific verb-resource pair ('Catalogue a book in Zotero') and lists explicit identifiers (ISBN, book DOI, title), clearly distinguishing the tool from siblings like attach_pdf.
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?
The description provides both when to use (cataloging books) and when not to (never a journalArticle), and gives an alternative (attach_pdf) for putting PDFs on the e-reader. It also explains behavior for loose matches and deduplication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![paperboy MCP server](https://glama.ai/mcp/servers/michaelellis003/paperboy/badges/card.svg)](https://glama.ai/mcp/servers/michaelellis003/paperboy)

Score Badge

Copy to your README.md:

[![paperboy MCP server](https://glama.ai/mcp/servers/michaelellis003/paperboy/badges/score.svg)](https://glama.ai/mcp/servers/michaelellis003/paperboy)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/michaelellis003/paperboy'

If you have feedback or need assistance with the MCP directory API, please join our Discord server