Provides tools for interacting with the INSPIRE REST API, enabling search and retrieval of literature and author records, resolution of DOI/arXiv/ORCID identifiers, citation export, and bibliography generation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@inspire-mcp Search for papers by John Ellis on supersymmetry"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An extensible Model Context Protocol server for the public INSPIRE REST API.
It provides structured tools for literature, authors, DOI/arXiv/ORCID resolution, citation export, and the INSPIRE bibliography generator. Responses offer bounded detail levels so an MCP client can trade metadata completeness for model context size.
Python 3.11 or newer
Related MCP server: scholar-toolkit-mcp
Install globally from a checkout:
uv tool install .Install from Git:
uv tool install git+https://github.com/karuboniru/inspire-mcpRun without a persistent install:
uvx --from git+https://github.com/karuboniru/inspire-mcp inspire-mcpThe default transport is stdio:
inspire-mcpFor a local Streamable HTTP endpoint:
inspire-mcp --transport streamable-http --host 127.0.0.1 --port 8000The endpoint is http://127.0.0.1:8000/mcp by default. Binding to a non-loopback
address requires --allow-public-http; production deployments should add authentication
and TLS in front of the server.
Example MCP host configuration:
{
"mcpServers": {
"inspire": {
"command": "inspire-mcp"
}
}
}Tool | Purpose |
| Search literature with INSPIRE query syntax |
| Read a paper by recid, DOI, or arXiv ID |
| Page through embedded paper authors |
| Page through a paper's references |
| Export BibTeX, LaTeX, or CV HTML |
| Search public author records |
| Read an author by recid or ORCID |
| Resolve DOI, arXiv, or ORCID to an INSPIRE recid |
| Generate a bibliography from TeX citation commands |
The inspire://capabilities resource describes supported values and limits.
compact: identity and discovery fields, optimized for model context.
standard: research-oriented metadata with bounded author arrays.
detailed: broad public metadata with explicit truncated_fields markers.
Large arrays are never byte-truncated. Use list_literature_authors and
list_literature_references to retrieve them in pages.
Author searches never expose email addresses. A single author record requires both
detail="detailed" and include_email=true before public email fields are included.
Environment variable | Default |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
INSPIRE documents an upstream limit of 15 requests per 5 seconds per IP. This server uses a lower default to preserve headroom and retries HTTP 429 responses conservatively.
Successful GET, search, and export responses are cached in each server process. Concurrent
identical requests share one upstream request. Set INSPIRE_CACHE_TTL_SECONDS=0 to disable
the cache. Multi-process deployments maintain one independent cache per worker.
Generated bibliography content is currently served by INSPIRE through CERN object storage.
The default download allowlist therefore contains both inspirehep.net and the exact host
s3.cern.ch; arbitrary external download hosts remain blocked.
uv sync --all-groups
uv run ruff check .
uv run mypy
uv run pytest
uv buildThe default tests use mocked HTTP responses. Live INSPIRE POST requests are not performed by the test suite.
Use of the upstream API is governed by the INSPIRE terms of use. Bulk collection of email addresses is not allowed.
Export one paper in an INSPIRE-supported citation format.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | content | |
| format | No | bibtex | |
| identifier | Yes | ||
| identifier_type | No | auto |
| Name | Required | Description |
|---|---|---|
| detail | Yes | |
| format | Yes | |
| content | Yes | |
| truncated | No | |
| source_url | Yes | |
| canonical_id | Yes | |
| content_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true and openWorldHint: true, covering the safety profile. The description adds that it produces citation formats, which is useful, but it does not disclose error behavior, prerequisites, or output structure beyond what the output schema likely provides. It is consistent with annotations and adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Export one paper in an INSPIRE-supported citation format.' It contains no filler and efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool, the description captures the primary action, and annotations provide safety, while the schema covers parameter options. However, missing usage guidance and parameter semantics leave the description incomplete for nuanced decisions like choosing this over generate_bibliography. It is minimally complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 explain any of the four parameters. The phrase 'citation format' vaguely maps to the format parameter, but identifier_type, detail, and identifier are left undefined. This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export one paper' with a specific verb and resource, and 'INSPIRE-supported citation format' distinguishes it from siblings like get_literature (metadata retrieval) and generate_bibliography (likely multi-paper export). This is a precise and unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only says 'one paper', implying single-record use, but does not mention when to prefer get_literature or generate_bibliography. No exclusions or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate BibTeX or formatted LaTeX bibliography content from TeX citations.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | content | |
| format | No | bibtex | |
| tex_source | Yes | TeX source containing \cite{...} commands understood by INSPIRE. |
| Name | Required | Description |
|---|---|---|
| detail | Yes | |
| errors | Yes | |
| format | Yes | |
| content | No | |
| truncated | No | |
| content_type | No | |
| download_url | No | |
| upstream_data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey safety/behavioral hints (idempotent, non-destructive, etc.), but the description adds no further behavioral context such as network usage or side effects. It essentially restates the tool's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the action and result. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse to fully guide an agent: it omits when to use the tool, what the format/detail options mean, and any behavioral notes. Despite having an output schema and annotations, the description alone leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers only 33% of parameters (tex_source has a description), and the tool description does not explain the 'detail' or 'format' enums, leaving the agent to guess what values like 'latex_eu' or 'diagnostic' produce.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Generate' and names the output ('BibTeX or formatted LaTeX bibliography content') and input source ('TeX citations'), clearly distinguishing it from sibling tools like export_literature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for converting TeX citations into a bibliography, but does not explicitly state when to choose it over alternatives like export_literature or search_literature. It provides clear input context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one author record, with explicit opt-in for public email addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | standard | |
| identifier | Yes | INSPIRE author recid or ORCID. | |
| include_email | No | ||
| identifier_type | No | auto |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| detail | Yes | |
| updated | No | |
| source_url | Yes | |
| record_type | Yes | |
| canonical_id | Yes | |
| truncated_fields | No | |
| requested_identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is known. The description adds the behavioral detail that public email addresses are only returned with explicit opt-in (include_email), which is useful. However, it does not disclose other behaviors such as how identifier_type auto-detection works or potential rate limits, so the additional context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 'Read one author record, with explicit opt-in for public email addresses.' It is front-loaded with the core action and adds the notable email opt-in detail without any wasted words. Perfectly sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, 2 enums, and a required identifier, but the description only addresses the core read action and email opt-in. It does not explain the detail parameter options or identifier_type resolution, which are essential for correct invocation. While an output schema exists, the input semantics are incomplete, making the description insufficient for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only the identifier parameter described. The tool description mentions email opt-in, which clarifies include_email, but it fails to explain the meaning of 'detail' levels or the 'identifier_type' behavior (auto, recid, orcid). With low schema coverage, the description must compensate, but it does not adequately do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and names the resource 'one author record', which clearly indicates the tool retrieves a single author by identifier. However, it does not explicitly distinguish itself from siblings like search_authors or list_literature_authors, so it misses the full specificity needed 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.
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 does not mention that it is appropriate when an identifier (recid or ORCID) is known, nor does it exclude cases where searching is more suitable. There is no statement about required inputs or prerequisites, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one literature record by INSPIRE recid, DOI, or arXiv identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | standard | |
| identifier | Yes | INSPIRE recid, DOI, DOI URL, arXiv ID, or arXiv URL. | |
| identifier_type | No | auto |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| detail | Yes | |
| updated | No | |
| source_url | Yes | |
| record_type | Yes | |
| canonical_id | Yes | |
| truncated_fields | No | |
| requested_identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds that the tool resolves multiple identifier types (recid, DOI, arXiv), which is useful behavioral context beyond the read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly conveys the tool's purpose without unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with an output schema, the description is adequate but not complete. It lacks information about the detail levels and identifier_type auto-detection, which may leave an agent uncertain about optional parameters. Sibling differentiation is minimal, though the purpose alone is fairly clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%. The description repeats the identifier types already in the schema but does not explain the 'detail' parameter (compact/standard/detailed) or the 'identifier_type' auto-detection behavior. This leaves a significant gap for agents needing to choose appropriate parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a single literature record using specific identifier types (INSPIRE recid, DOI, or arXiv identifier). This distinguishes it from sibling tools like search_literature or list_literature_authors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a specific identifier and need the corresponding record, providing clear context. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident 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.
Page through a paper's embedded author list without returning a huge record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items to return. | |
| detail | No | names | |
| offset | No | Zero-based collection offset. | |
| identifier | Yes | ||
| identifier_type | No | auto |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| limit | Yes | |
| total | Yes | |
| detail | Yes | |
| offset | Yes | |
| has_more | Yes | |
| collection | Yes | |
| source_url | Yes | |
| canonical_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context by noting this is a paginated listing operation ('Page through') and specifying the resource scope ('embedded author list'), which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that conveys the core purpose, pagination behavior, and avoids huge records. Every word earns its place with no redundancy or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and a low schema description coverage, but annotations and an output schema are present. The description explains the core listing and pagination behavior but lacks guidance on identifier specification and parameter semantics, making it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description does not explain critical parameters like identifier, identifier_type, or detail. It only implicitly references the paper via the word 'paper' without providing meaning for how to specify it. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Page through'), the resource ('a paper's embedded author list'), and the intent ('without returning a huge record'). It distinguishes this tool from siblings like list_literature_references by specifying authors embedded in the paper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 this tool: to paginate through an embedded author list and avoid large records. It does not explicitly name alternatives or exclusions, but the pagination-focused wording implies its intended use case well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Page through a paper's references with selectable detail.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | compact | |
| offset | No | Zero-based collection offset. | |
| identifier | Yes | ||
| identifier_type | No | auto |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| limit | Yes | |
| total | Yes | |
| detail | Yes | |
| offset | Yes | |
| has_more | Yes | |
| collection | Yes | |
| source_url | Yes | |
| canonical_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds minimal behavioral context (pagination, selectable detail) but does not disclose sorting, rate limits, or other traits. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and free of unnecessary wording. It earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and only 20% schema coverage, the description is too brief to fully contextualize usage. It omits guidance on identifier_type and usage scenarios, though output schema and annotations reduce the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), so the description must compensate. It does by indicating 'a paper's references' (identifier refers to a paper) and 'selectable detail' (detail parameter), but it does not explain identifier_type or pagination semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: paging through a paper's references with selectable detail. It uses a specific verb ('Page through') and identifies the resource ('a paper's references'), distinguishing it from sibling tools like list_literature_authors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_literature or list_literature_authors. It does not mention any exclusions or specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve DOI, arXiv, or ORCID to a canonical INSPIRE record identity.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | identity | |
| identifier | Yes | DOI, arXiv ID, ORCID, or the corresponding URL. | |
| identifier_type | No | auto |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| detail | Yes | |
| source_url | Yes | |
| record_type | Yes | |
| canonical_id | Yes | |
| identifier_type | Yes | |
| normalized_identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and scope. The description adds the specific output concept (canonical record identity) and accepted identifier types, but does not go deeper into behaviors like error handling or what happens with unknown identifiers. This adds some value but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the core purpose. Every word earns its place, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, output schema present), the description provides the essential purpose but misses important context: the meaning of the 'detail' parameter and when to prefer this over sibling search tools. The output schema likely covers return values, but parameter semantics are incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'identifier' has a description). The description does not explain 'detail' or 'identifier_type' beyond what their enum names suggest. 'detail' is ambiguous (identity vs summary vs record) and the description fails to compensate for this low coverage, leaving the agent without sufficient semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves DOI, arXiv, or ORCID to a canonical INSPIRE record identity. This specific verb (resolve), resource (external identifiers), and output (canonical identity) fully distinguish it from sibling tools like search_literature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool: when you hold an external identifier (DOI, arXiv, ORCID) and need the corresponding INSPIRE record identity. It does not explicitly state exclusions or alternatives, but the purpose is sufficiently clear that an agent would know not to use this for generic searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public INSPIRE author records; email addresses are always excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | Yes | ElasticSearch query such as 'ids.value:INSPIRE-00140145' or 'name.value:Hawking'. | |
| detail | No | compact | |
| page_size | No |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| items | Yes | |
| query | Yes | |
| total | Yes | |
| detail | Yes | |
| next_url | No | |
| page_size | Yes | |
| source_url | Yes | |
| record_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds a meaningful behavioral detail: email addresses are always excluded from results. This is a specific privacy constraint that is not implied by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys purpose and a key constraint. No filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is clear and the output schema exists, it does not explain pagination, detail levels, or query syntax beyond what the schema provides. The missing descriptions for three parameters make the tool less complete than it could be, but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 25% (only the query parameter has a description). The tool description does not compensate for the undocumented page, detail, or page_size parameters, providing no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches public INSPIRE author records, with a specific verb and resource. It distinguishes from siblings like get_author (singular fetch) and search_literature (literature search) by focusing on author search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to search public author records. It does not explicitly name alternatives or exclusions, but the intent is unambiguous given sibling tool names like get_author.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search INSPIRE literature with bounded, model-oriented result detail.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | One-based result page. | |
| sort | No | default | |
| query | Yes | INSPIRE query such as 'a E.Witten.1', 'topcite 1000+', or 'dois.value:*'. | |
| detail | No | compact | |
| page_size | No | Results per page. |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| items | Yes | |
| query | Yes | |
| total | Yes | |
| detail | Yes | |
| next_url | No | |
| page_size | Yes | |
| source_url | Yes | |
| record_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, indicating safe reads from a dynamic source. The description adds 'bounded' and 'model-oriented result detail', which suggest pagination/limits and configurable output detail, but these terms are vague. It does not contradict annotations, so a 3 reflects the marginal context added beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the action ('Search INSPIRE literature') and adds a compact qualifier. Every word contributes to the overall meaning, even if the qualifier is somewhat opaque.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, an output schema, and multiple siblings, the description is too sparse. It fails to clarify query semantics, pagination bounds, sorting options, or when to choose this over other literature tools. The output schema reduces the need to describe returns, but the description still lacks essential context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself adds no explicit parameter explanations. Schema coverage is 60% (query, page, page_size have descriptions; sort and detail only have enums). The phrase 'model-oriented result detail' loosely implies the detail parameter but isn't definitive. Since schema covers the main parameters and enum values are self-descriptive, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search INSPIRE literature' with a specific verb and resource, and adds 'bounded, model-oriented result detail' which hints at unique behavior. The name and title alone already distinguish it from sibling search_authors, get_literature, etc., so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like get_literature, list_literature_references, or export_literature. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource or action: literature search vs retrieval, listing authors vs references, exporting single papers, author search vs retrieval, external ID resolution, and bibliography generation. There is no meaningful overlap that would confuse an agent.
All tools follow a consistent verb_noun pattern (e.g., search_literature, get_author, list_literature_references). Naming is uniformly snake_case and predictable, making the tool set easy to navigate.
Nine tools is well-scoped for an INSPIRE literature and author database interface. Each tool serves a clear purpose without redundancy, and the count is within the ideal range for a domain-specific server.
The set covers core workflows: searching and retrieving literature, exploring authors and references, exporting citations, resolving external identifiers, and generating bibliographies. Minor gaps exist, such as no batch citation counts or citation-of tracking, but these are not critical for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Altmetric APIs - track research attention across news, policy, social media, and more
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
IEEE Xplore MCP — BYOK wrapper over the IEEE Xplore Metadata Search API
Academic research MCP server for paper search, citation checks, graphs, and deep research.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/karuboniru/inspire-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
