paperSearch

by FreddieWho

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Several tools have overlapping purposes: search_literature vs. search_literature_signals both search, resolve_identifiers vs. convert_identifiers both handle IDs, and find_related_articles vs. expand_from_work both find related works. Descriptions clarify differences, but confusion is possible.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (search_literature, get_work, resolve_identifiers, export_records). Minor deviations like expand_from_work (verb-preposition) and lookup_mesh (terse) exist but do not disrupt overall predictability.
Tool Count5/5
With 11 tools, the set is well-scoped for a literature search server. Each tool serves a distinct step in discovery, retrieval, and export without unnecessary redundancy or bloat.
Completeness4/5
The tool set covers the core scholarly search workflow: planning, searching, retrieving by ID, converting identifiers, expanding from known works, and exporting. Minor gaps exist, such as full-text retrieval or advanced citation analysis, but they are not critical for the stated purpose.
Average 2.8/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on July 10, 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.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'export' without explaining output format options (beyond 'supported format'), side effects, permissions, or whether the tool returns data or writes to a file. There is no mention of destructive actions, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the key information and is appropriately concise for a simple export tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too thin for a tool with no annotations. It omits usage context, format enumeration, and any behavioral warnings. The tool is simple, but the description should still clarify supported formats or provide pointers to sibling tools for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 does allude to 'list of works' (mapping to 'works') and 'supported format' (mapping to 'format'), but gives no details on the structure of the 'works' objects, allowed format values, defaults (e.g., 'jsonl'), or constraints. This is minimal added meaning beyond the schema.
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 'Export a list of works to a supported format' clearly states the action (export), the resource (list of works), and the target (supported format). It is distinct from sibling tools like search_literature or get_work, though it does not explicitly differentiate itself from them by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or when not to use it. Sibling tools are not referenced, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. It fails to mention that a valid PMID is required, how the limit parameter affects results, or any error/edge-case behavior. The description only states the output type without any 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?
The description is a single concise sentence with no wasted words, and the key resource is front-loaded. However, it is so brief that it borders on under-specification, though for the purpose of conciseness it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and no annotations, the description is incomplete. It does not explain the role of the input PMID or the meaning of limit, nor does it provide usage context. The output schema exists, so return values need not be described, but the lack of parameter and usage context makes it insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the parameters 'pmid' or 'limit'. Since the schema provides no descriptions, the text should have explained these parameters but does not, leaving the agent without semantic guidance for invocation.
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 'Find PubMed related article PMIDs.' uses a clear action verb 'Find' and identifies the resource as PubMed related article PMIDs. It implicitly distinguishes from sibling tools like search_literature, which searches by query, and expand_from_work, which likely expands from a work record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention scenarios such as 'use when you have a PMID and want related articles' or exclude cases better served by search_literature or expand_from_work. The description merely states functionality.
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?
With no annotations, the description carries full burden for behavioral disclosure. It fails to mention how results are ordered, how sources are selected, caching behavior, or any side effects. The tool remains opaque beyond the basic search function.
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 a single, front-loaded sentence with no redundancy or extraneous content. It is concise, though under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, output schema present), the description is severely incomplete. It lacks any context about return behavior, source configuration, or search semantics, making it difficult for an agent to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter semantics. With 11 parameters, including filtering options like venue, year, and open_access_only, the description does nothing to clarify their usage or meaning.
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 open scholarly literature, using a specific verb and resource. It distinguishes from sibling tools like get_work (retrieving specific works) or resolve_identifiers (ID mapping), though it doesn't explicitly differentiate from other search variants like plan_literature_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states its primary function without mentioning specific use cases, prerequisites, or exclusions.
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 must carry the full burden of behavioral disclosure. It only says 'Search' and 'via PubTator3', which implies a read-only external lookup but does not explain result behavior, rate limits, authentication, or the meaning of 'signals'. This is insufficient for a tool with no annotation support.
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 a single sentence that is front-loaded with the action and includes a meaningful qualifier ('via PubTator3'). It contains no fluff or redundancy, but the brevity comes at the cost of critical detail, which is a completeness concern rather than a conciseness flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, six optional parameters, and the existence of a closely related sibling 'search_literature', this one-sentence description is inadequate. It does not explain what a 'signal' is, when to prefer this tool, or how parameters combine. The presence of an output schema helps but cannot compensate for the lack of contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description was expected to explain the roles of the 6 parameters, especially 'entity1', 'entity2', 'entity2_type', and 'relation_type'. It adds no parameter information beyond the raw property names, leaving the interaction between parameters and the 'signal' concept completely unexplained.
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 uses the verb 'Search' and identifies the resource as 'biomedical literature signals via PubTator3', which distinguishes it from the generic sibling tool 'search_literature'. However, 'signals' is not defined, so the purpose is clear but not fully precise about what constitutes a signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'search_literature' or 'find_related_articles'. There are no exclusions, prerequisites, or context cues about appropriate use cases.
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, and the description does not disclose behavioral traits such as whether the operation is read-only, any network dependencies, rate limits, or error conditions. The phrase 'through the NCBI ID converter' hints at an external call but does not elaborate. This is insufficient for a tool with no annotation support.
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 a single, concise sentence that communicates the core function efficiently. It is front-loaded and contains no unnecessary words, earning top marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is too sparse for the tool's context. It does not clarify the conversion direction, possible limitations, or what the output represents beyond the schema. The tool has one parameter and no annotations, so the description should carry more contextual weight than it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'identifiers' parameter with minimal type info, and the description provides no additional meaning about the parameter—such as acceptable formats, examples, or expected identifier syntax. With schema description coverage at 0%, the description fails to compensate, leaving the agent to guess.
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 uses the specific verb 'Convert' and names the resource 'DOI/PMID/PMCID identifiers through the NCBI ID converter,' clearly stating what the tool does. It lacks an explicit distinction from the sibling tool 'resolve_identifiers,' so it does not fully meet the 'distinguishes from siblings' criterion for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'resolve_identifiers' or 'search_literature.' The description simply states the action without any context or exclusionary guidance, so it fails to help an agent decide between similar tools.
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, and the description gives no behavioral details such as whether the operation is read-only, what the output shape is, or how edge cases are handled. The burden is on the description, and it does not carry it.
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 a single focused sentence with no filler. It is concise and front-loads the core purpose, though it could be expanded with more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, zero parameter descriptions, and no usage guidance, the description is insufficient for an agent to confidently invoke the tool correctly. There is no mention of output behavior or how to configure the expansion despite the presence of five parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only hints at the 'by' parameter through 'citations, references, or similar papers.' It does not explain 'identifier', 'limit', 'sources', or 'source_modes', leaving most parameters semantically opaque.
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 that the tool expands from a known work using citations, references, or similar papers, providing a specific verb and resource. It is reasonably distinct from siblings like search_literature, though it overlaps with find_related_articles on 'similar papers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage from a known work but provides no explicit guidance on when to prefer this tool over alternatives, nor does it mention exclusions or prerequisites. Sibling tools are not referenced.
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 must carry the full burden. It discloses that the tool does not run a live search, but it does not explain what it actually returns, whether it is read-only, or any side effects. For a planning tool, this is a significant gap in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that avoids waste. However, it is somewhat under-specified, and the lack of structure or elaboration makes it only minimally adequate. It earns a middle score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too thin to understand the tool's purpose fully. It doesn't explain what 'source routing' or 'ranking' mean, or how the query influences the plan. For a 3-parameter tool with no annotations, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters (query, sort, profile). It does not add any meaning beyond the raw schema, leaving the agent without guidance on how to populate or interpret these parameters.
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 uses the verb 'Plan' and clearly differentiates from a live search by saying 'without running a live search.' This distinguishes it from sibling tools like search_literature. However, the phrase 'source routing and ranking' is somewhat vague and not fully explained, keeping it from a 5.
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 implies usage when a user wants to plan or preview rather than execute a live search. It does not explicitly name alternatives, but the contrast with 'live search' gives clear context. There are no explicit exclusions, but the guidance is sufficient.
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 only states that identifiers are resolved and merged records are returned, but does not disclose whether the operation is read-only, how missing identifiers are handled, what 'merging' entails, or any authorization/rate-limit concerns.
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 a single, tightly worded sentence that front-loads the verb and resource. There is no unnecessary information, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and a non-trivial merging behavior, the one-line description is insufficient. It does not explain parameter semantics, usage conditions, or edge cases. The presence of an output schema covers return values but not the tool's operational nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage. The description alludes to 'sources' but does not explain the identifiers, sources, or source_modes parameters, their formats, defaults, or how they interact.
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 the action ('Resolve') and the resource ('a list of identifiers across sources') and the output ('return merged records'). It differentiates from sibling tools like convert_identifiers by focusing on lookup and merging rather than simple conversion, though it could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool over alternatives such as convert_identifiers or search_literature. It implies its purpose but lacks explicit context, prerequisites, or exclusions.
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 only states a basic lookup action without disclosing any behavioral details like authentication requirements, return format limitations, or query behavior (e.g., exact vs fuzzy matching). This is insufficient for transparent behavioral understanding.
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 a single concise sentence that immediately conveys the core function. It is efficiently front-loaded with no wasted words, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and an output schema exists, the description lacks contextual guidance on when to use it and what behavioral caveats exist. Given no annotations and minimal description, the overall context is incomplete for an agent to confidently select and invoke this tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 0% of parameters in descriptions. The description only hints at 'a biomedical term,' which corresponds to the 'term' parameter, but it does not explain the 'limit' parameter or the expected input format. Given the zero schema description coverage, the description fails to compensate for parameter semantics.
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 states a specific action ('Lookup') with a clear resource ('MeSH descriptors') and input ('a biomedical term'). It is distinct from sibling tools like search_literature and resolve_identifiers, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention relationships to sibling tools or any exclusions, leaving usage context entirely implied.
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 only states 'Return the health status' with no additional context about network access, side effects, or what 'configured sources' entails. The read-only nature is implied by the name but not disclosed.
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 a single, focused sentence with no wasted words. It is well-structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with an output schema, the description covers the core purpose. However, it lacks any explanation of the `include_catalog` parameter and provides no usage context, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the `include_catalog` parameter at all. With schema coverage at 0%, the parameter's meaning and effect are entirely undocumented, leaving the agent to guess.
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 function with the verb 'Return' and the resource 'health status of all configured sources.' This distinguishes it from the sibling tools, which all focus on literature search, identifiers, or records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It merely states what it does, without any exclusions, prerequisites, or alternative tool mentions.
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 of behavioral disclosure. It only states the retrieval action and does not disclose whether the operation is read-only, any required permissions, rate limits, or data completeness expectations. This is a significant gap given the lack of annotation support.
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 a single sentence that front-loads the essential purpose. Every word is informational and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core function is clear, the tool has four parameters and multiple sibling tools. The description does not explain how optional parameters affect behavior, nor does it provide usage context or contrast with related tools. For a tool with moderate complexity and no annotations, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has four parameters with zero coverage in the description. Only 'identifier' is implicitly explained via the phrase 'by identifier'; sources, source_modes, and identifier_type are entirely unexplained. The description fails to compensate for the low schema coverage.
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 specific verb 'get' and resource 'work', and enumerates identifier types (DOI, PMID, PMCID, arXiv), which clearly defines the tool's scope. This distinguishes it from sibling tools like convert_identifiers or resolve_identifiers that focus on identifier mapping rather than retrieving the full work record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as resolve_identifiers or convert_identifiers. It implies usage when an identifier is at hand but does not state exclusions or mention alternatives, leaving the agent to infer the correct choice.
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:

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

Score Badge

Copy to your README.md:

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

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/FreddieWho/searchPaper'

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