com.luneresearch/lune

Server Quality Checklist

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

Latest release: v1.5.1
Disambiguation5/5
Each tool has a clearly distinct purpose: search papers, search with multiple queries, find similar papers, get full text, get citations, browse conferences, manage subscriptions, verify claims, etc. Even similar-sounding tools like search_papers and search_papers_many are well-differentiated by their descriptions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., search_papers, get_paper_fulltext, list_conferences). No mixing of conventions or cryptic names.
Tool Count5/5
With 16 tools, the set is well-scoped for a research assistant. Each tool serves a specific need, and there is no redundancy or bloat. The count is appropriate for the domain.
Completeness5/5
The tool surface covers the full research workflow: search (multiple angles), retrieval of details, citations, guidance, fact-checking, and subscription management. There are no obvious gaps that would prevent an agent from performing common research tasks.
Average 4.6/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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?
Annotations are minimal (no destructiveHint, idempotentHint, etc.), so the description adds valuable behavioral context: it explains that new papers indexed after this call appear in get_subscription_updates. This discloses the downstream effect beyond simple parameter entry.
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 extremely concise: two sentences with no filler. The first sentence states the purpose and usage triggers; the second adds behavioral detail. Every sentence earns its place, and content is front-loaded.
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 tool has 4 parameters and an output schema, the description is sufficient. It covers the core behavior, result linkage to get_subscription_updates, and resolution hint for conference. It does not detail every parameter but the schema and output schema fill remaining gaps. Slightly above average completeness.
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 50% (email and conference have descriptions, notify_email and notify_in_app have defaults but no schema description). The description adds meaning for the conference parameter (resolution method) but does not elaborate on email or the notification booleans. It partially compensates for the coverage gap, but not fully.
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 the tool's purpose: "Use this when the user asks to follow / track / watch / subscribe to a conference." It clearly identifies the verb (subscribe) and resource (conference), and distinguishes it from sibling tools like unsubscribe_conference and get_subscription_updates.
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 clear context for when to use (user actions like follow/track/watch/subscribe) and mentions that conference resolution works like search_papers, avoiding unnecessary lookup. However, it does not explicitly state when not to use or name alternative tools, though the context is strong enough for an AI agent.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds important behavioral context: the tool is 'heavy' (suggests constraint on number of calls) and explains the two output formats with their intended uses.
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?
Concise and well-structured. Every sentence adds value: use case, heavy warning, format explanation, section parameter. Front-loaded with purpose, then usage guidelines, then parameter details.
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?
Completeness is high given the tool's complexity (3 params, no output schema). It explains the heavy nature, section filtering, and format selection. Could be more explicit about exact output structure but current info is sufficient for a read 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?
Schema coverage is 100%, so baseline is 3. The description adds meaning: explains the difference between format values (markdown vs json), the purpose of sections (case-insensitive heading match), and where paper_id comes from (linked to other tools).
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's purpose: retrieving full text when abstract isn't enough or for quoting. It distinguishes from sibling search tools by specifying use cases and referencing `search_papers` etc. for obtaining the paper_id.
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 when-to-use scenarios (abstract insufficient, quoting) and a strong usage guideline: 'only call once a paper looks relevant'. It does not explicitly name alternative tools but implies not to use for initial search.
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?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context about sorting (recency vs citations) and pagination (limit/offset), which is beyond annotations.
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 sentences, zero waste, front-loaded with usage guidance. Every sentence serves a purpose: first tells when to use, second explains sort and pagination.
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?
All essential aspects are covered: conference, year, sorting, pagination. An output schema exists, so return values need not be explained. The description is complete for its intended use.
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 100%, so baseline is 3. The description adds meaning by clarifying the sort parameter with intended values and providing a concrete example for the conference parameter. Pagination parameters are also briefly explained.
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 retrieves papers from a specific conference with optional year filtering. Examples like 'most-cited NeurIPS 2024 papers' make the purpose concrete, and it is well-differentiated from sibling tools like search_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?
The description explicitly says 'Use this when the user asks for papers from a specific conference' and gives usage examples. It implies alternative tools exist for non-conference queries but does not name them directly, so it lacks explicit when-not-to-use guidance.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Description adds important behavioral details: cites direction returns parsed references that may not be in corpus, and pagination behavior (total, has_more). No contradictions.
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 sentences, front-loaded with use cases, no wasted words. Essential information presented efficiently.
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?
With complete input schema, clear annotations, and output schema (presumed to document return fields), the description covers all necessary context: direction semantics, pagination, and appropriate use cases. No gaps.
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 100%, so baseline 3. Description adds value by explaining the meaning of direction values in terms of influence chains and clarifying pagination behavior, exceeding basic schema documentation.
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?
Description explicitly states the tool retrieves citations in two directions (cited_by and cites) and lists specific user queries it addresses (e.g., 'what does this paper build on', 'what built on this'). Clearly distinguishes from sibling tools like search_papers by detailing the citation-specific functionality.
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 use cases and explains the two directions and pagination. Does not explicitly state when not to use it or mention alternatives, but the context is clear enough for selection.
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?
Discloses behavioral traits beyond annotations: merged feed, cursor-aware pagination, cheap to run. Annotations are neutral; no contradiction.
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 focused sentences, front-loaded with usage examples, no wasted words.
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?
Covers usage, behavior, parameter semantics, and output structure. Output schema implied; no gaps remain.
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?
Adds meaning over schema by explaining cursor usage for 'since' parameter. With 50% schema coverage, description compensates effectively for the undocumented 'since' parameter.
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 retrieves new papers from subscriptions, explicitly maps to user intents ('any new papers', 'give me a digest'), and distinguishes from siblings like get_conference_papers (per conference) and list_subscriptions.
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 when-to-use triggers and cursor usage instructions. Lacks explicit when-not-to-use or alternative tool mentions, but the context is clear.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds context about optional filtering by category and matches research area. It does not mention pagination or return format, but with annotations covering safety and no output schema issues, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous words. It immediately states when to use, gives concrete examples, and explains parameter usage. Every sentence earns its place.
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 is simple (one optional parameter, read-only, with output schema), the description is fully adequate. It covers purpose, usage context, and parameter behavior. No additional context is needed for an AI agent to correctly select and invoke this 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?
Schema coverage is 100% and the description adds value by explaining how the category parameter matches the conference's research area, listing example codes (ai, security) and noting case-insensitivity. This goes beyond the schema's description of 'Optional research-area filter' and provides practical guidance.
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 specifies the verb 'list' and resource 'conferences tracked by Lune', and gives concrete user queries that trigger its use (e.g., 'what conferences does Lune track', 'is venue X covered'). It also distinguishes from siblings by noting category-level browsing, unlike get_conference_papers (for specific conference) or subscribe_conference (for subscription).
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 states when to use (user asks about tracked conferences, venue coverage, category browse) and provides examples of intended usage. It does not explicitly state when not to use or name alternatives, but the context (sibling tools) and the phrase 'category-level browse' imply differentiation. A more explicit exclusion would improve this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it returns subscription ID and conference ID, but no further behavioral context. With good annotations, the description adds minimal extra behavioral detail.
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?
Three sentences, front-loaded with usage guidance, then return info, then alternative. No wasted words. Each sentence serves a purpose.
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, full schema coverage, output schema present, and annotations covering behavioral traits, the description is complete. It covers usage, return structure, and alternative 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?
Tool has zero parameters, so baseline per instructions is 4. Description does not need to add parameter info. Schema coverage is 100%.
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?
Description explicitly states the tool lists conference subscriptions and provides example queries like 'what conferences am I tracking'. It mentions return fields (subscription ID and conference ID). Distinguishes from sibling get_subscription_updates.
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?
Clearly states when to use (user asks about subscriptions) and provides an explicit alternative: 'To fetch new papers across all of them, call get_subscription_updates (no id needed).'
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?
The description discloses behavior beyond annotations: it runs one corpus search per angle, decomposes tasks, returns coverage status, evidences spans, next queries, and supports draft checks. It explains billing (len(queries) for one-shot, max_total_queries for iterative) and constraints. Annotations readOnlyHint true is consistent with 'without the tool writing the answer'. No contradiction.
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 somewhat lengthy but well-structured: opening with purpose, then parameter explanations, then additional notes on billing and output. It front-loads the core use. Some redundancy (billing mentioned twice) but generally efficient for the complexity (11 parameters). Score 4.
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, the description covers all necessary aspects: what it does, how it works, parameter usage, billing, optional features (requirements, draft), and what returns (coverage status, evidence spans, next queries). The output schema exists, so return values need not be fully detailed, but the description still gives a good overview. Complete and actionable for an AI agent.
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 73% schema coverage, the description adds value by explaining parameter semantics (e.g., task drives decomposition, queries each run a search, max_iterations default and behavior, draft usage). It provides context beyond schema descriptions, but the schema already includes basic descriptions. The description enhances understanding, justifying a 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's purpose: to assess sufficiency of gathered evidence for a multi-part research task, distinguishing it from siblings like search_papers or extract_from_papers. It specifies the action (gather evidence and judge sufficiency) and the resource (evidence), meeting the 5 criteria.
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 when-to-use guidance: when needing to know sufficiency, what is missing, and what to search next. It contrasts with not using it for writing the answer, implying the agent writes the answer. It also describes typical workflow and optional parameters. However, it could be more explicit about when not to use (e.g., simple search). Clear but not exhaustive.
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?
Beyond annotations (readOnlyHint, openWorldHint, non-destructive), the description details the process: retrieval + LLM judging only against passages, verdict types, verbatim quote guarantee, confidence/reasoning, and filter sharing. No contradictions with annotations.
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 purpose and efficiently covers process, output, and usage nuances. At ~150 words, it is well-structured but slightly longer than necessary; could be tightened marginally.
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 7 parameters (100% schema coverage), output schema present, and sibling tools, the description is comprehensive. It explains verdicts, quote guarantees, confidence/reasoning, filter sharing, and handle usage. No major gaps; the open-world nature is addressed via insufficient_evidence.
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 covers 100% of parameters with descriptions. The description adds value by explaining that filters are shared across claims, that paper_ids are handles not for display, and that claims should be self-contained assertions. This compensates beyond 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's purpose: fact-checking 1-25 claims against a corpus in one call, with verb 'fact-check' and specific resource. It distinguishes from sibling tools like search_papers by focusing on verdict generation, and explicitly mentions use cases like grounding drafts or vetting claims.
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: 'ground a draft before you assert it, to vet a user's claim, or to check your own answer against the literature.' It implies when to use over memory-based answers but lacks explicit when-not or alternative comparison. However, the context is clear.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds important behavioral details: returns abstract, contexts, similarity score, and explains error conditions (unknown paper_id is error, empty list means no neighbors). No contradictions.
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?
Three sentences with zero waste. The first sentence distinguishes the tool, the second provides usage context and sibling, the third explains return fields and error behavior. All essential information is front-loaded.
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 (implied by description of return fields), the description is complete. It covers purpose, usage, parameters, return values, and edge cases (unknown paper_id, empty result). No gaps.
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 50%. The description clarifies that limit controls the number of returned papers (up to) and that paper_id must be valid (error if unknown). It adds meaning beyond the schema, which only provides type and constraints.
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 names the tool as returning semantically similar papers by embedding distance, not citation links, and provides the use case 'more papers like this one'. It contrasts with sibling get_paper_citations, making the distinction unambiguous.
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 (for similar papers on the same topic) and when not to use (for citations, use get_paper_citations). This provides clear guidance for an agent to select the correct 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?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds valuable behavioral context beyond annotations, specifically that the cursor is discarded and resubscribing starts fresh. This is useful for an agent to understand side effects.
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 three sentences long, with the first sentence stating the purpose, the second providing usage guidance, and the third clarifying a behavioral consequence. No unnecessary words.
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?
For a simple one-parameter tool that likely returns a standard result (output schema exists), the description covers the needed information: when to use, how to get the parameter, and what happens upon use. It is complete enough for an agent to invoke 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?
Schema coverage is 0%, so description must explain the parameter. It does so by directing the agent to 'Pass the subscription_id from list_subscriptions', which adds practical context beyond the schema's type and minLength constraint.
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 specific verbs ('stop following', 'unsubscribe', 'drop') and the resource ('conference'), and distinguishes it from the sibling tool 'subscribe_conference' and other subscription-related tools.
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 explicitly states when to use this tool ('when the user asks to stop following / unsubscribe / drop a conference') and provides a crucial prerequisite: pass the subscription_id from list_subscriptions. It also clarifies the consequence of use (cursor discarded).
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds critical behavioral details: model uses only stated facts, may leave fields null, truncation flag, failed papers reported separately, and the heavy cost. No contradictions.
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 relatively long but each sentence adds value. It is front-loaded with the main action and structured logically. Minor redundancies (e.g., 'the model is instructed to use only what each paper states' appears twice) could be trimmed, but overall 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?
For a complex tool with 4 parameters and output schema (not shown), the description covers edge cases (truncation, failed papers), usage constraints (heavy cost, relevance prerequisite), and distinguishes from siblings. It leaves no major gaps for an AI agent to misunderstand.
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 100%, so baseline is 3. The description adds practical context for each parameter: fields define columns, instruction is natural-language guidance, sections focus extraction, paper_ids come from search results. It provides meaningful usage guidance 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 core action: 'Pull a structured table out of up to 50 papers in ONE call: you define the columns...' It specifies the verb (extract), resource (papers), and the structured output. It distinguishes from siblings like get_paper_fulltext (single paper raw text) and gather_evidence.
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?
Explicit when-to-use guidance: 'Use this when you need the SAME facts across many papers... instead of reading each full text yourself and transcribing by hand.' Also provides a when-not-to-use hint: 'Heavy: one model call per paper, so extract only papers you already judged relevant.' Contrasts with get_paper_fulltext.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive; description adds sequencing context (after search) and purpose, but no additional behavioral traits beyond that.
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?
Single sentence with clear imperative and front-loaded usage guidance; every word is purposeful.
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?
For a simple retrieval tool with one param and output schema, the description fully covers when and how to use, meeting the needs of an AI agent.
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 high coverage (1 param described), and description adds value by noting doc_id comes from a search hit, not just any UUID.
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?
Clearly states the tool retrieves the full text of a guidance document after search, distinguishing it from search_research_guidance which only returns excerpts.
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 when to use (after search_research_guidance when full text needed) and provides examples (quoting, following checklist). Specifies to pass doc_id from search hit.
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?
Annotations indicate read-only, open-world, non-destructive. Description adds details on hybrid search, scores, rerank behavior, low_confidence flag, and the internal nature of `paper_id`. No contradiction.
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 long but structured, starting with the core use case and progressing to details. Every sentence adds unique value; 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?
Covers pagination, sorting, filtering, confidence thresholds, and output handling. With an output schema present, the description completes the picture for effective tool use.
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 coverage is 80%, and the description adds meaningful context for parameters like `query` (natural-language preference), `detail`, `offset`, and `sort_by`. It explains behaviors not obvious from schema alone.
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's purpose: searching academic papers. It specifies when to use it (research questions, literature reviews) versus `web_search`, and distinguishes it from siblings like `search_papers_many`.
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?
Explicitly tells when to use this tool instead of `web_search` and provides trigger questions. Missing explicit when-not-to-use scenarios, but the guidance is strong.
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?
The description adds significant context beyond annotations: explains the corpus is curated from senior researchers, warns about hallucination-prone nature of methodology questions, and describes the output (top-K excerpts with source attribution). No contradiction with readOnlyHint or idempotentHint.
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 reasonably concise given the depth of guidance, with key information front-loaded. Every sentence contributes value (usage, alternatives, examples, output format). Minor redundancy could be trimmed.
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 simple input schema, rich annotations, and existence of an output schema, the description thoroughly covers when to use, what it does, and what it returns. No obvious gaps for agent decision-making.
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?
Although the schema has 0% description coverage, the description implies the limit parameter via 'top-K excerpts' and the query parameter is clear from context. Provides enough semantic meaning for an agent to understand usage, though explicit parameter mapping would improve.
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 that the tool searches a curated corpus of research methodology guidance for experimental design, evaluation, etc. It distinguishes itself from web_search by specifying its curated source, making the purpose unambiguous.
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 instructs to use this before recommending methodology, and provides a direct alternative (web_search) with reasons. Includes triggering questions to help the agent decide when to invoke.
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?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds extensive behavioral context: hybrid pipeline (Cohere Embed v4 + BM25 + Cohere Rerank v3.5), RRF merging, dedup, envelope reporting (queries_run, queries_failed), has_more always false, and paper_id usage restrictions. No contradictions.
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 lengthy but well-structured, front-loading the core purpose and usage guidelines. Every sentence adds value, covering behavioral details, parameter semantics, and output explanation. Could be trimmed slightly, but the structure justifies its length given the tool's 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 the tool's complexity (multi-query, merging, filtering) and the presence of an output schema, the description fully explains the output: deduped list with provenance, envelope fields, error handling (queries_failed), and detail modes. It also covers billing and how paper_id should be used, leaving no 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?
Schema coverage is 100%, and the description adds significant value beyond schema: for 'queries' it explains the diversity requirement and natural language phrasing; for 'detail' it clarifies output trade-offs; for filters it notes they are shared across queries. It also explains how parameters affect the output (e.g., limit, year ranges).
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 it is for 'LITERATURE SWEEP or survey' and for 'research question broad enough to need several angles', explicitly distinguishing it from web_search and single-query search_papers. It specifies that it returns peer-reviewed papers with citable paper_id, making the purpose highly 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: for broad surveys, related-work sections, or state-of-the-field summaries. It advises preferring this over web_search and repeated search_papers, and for single focused questions to use search_papers. It also gives detailed query formulation tips and billing implications.
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:

[![lune-mcp-server MCP server](https://glama.ai/mcp/servers/RetrogradeLabs/lune-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/RetrogradeLabs/lune-mcp-server)

Score Badge

Copy to your README.md:

[![lune-mcp-server MCP server](https://glama.ai/mcp/servers/RetrogradeLabs/lune-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/RetrogradeLabs/lune-mcp-server)

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/RetrogradeLabs/lune-mcp-server'

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