Which integrations are available for this server?

Validates DOI references by normalizing DOI input and independently checking metadata through DOI CSL-JSON content negotiation and registry sources. Provides optional read-only integration with a Zotero library, allowing exact normalized DOI matching for reference validation and enrichment without writing or modifying Zotero data.

How do I use rag-reference-discovery-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rag-reference-discovery-mcp Find and validate scholarly references for this paragraph." 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.

rag-reference-discovery-mcp

by flatmarstheory

Overview Schema Source Related Servers Discussions Admin

Python

Remote

rag-reference-discovery-mcp

A production-oriented, read-only MCP server for discovering and independently validating scholarly metadata from text extracted by an MCP client's own attachment/RAG system.

Purpose and non-goals

The server accepts extracted assignment or research text, identifies deterministic local-NLP search concepts, queries Crossref, OpenAlex, and supplementary DataCite metadata, ranks candidates, and validates DOI metadata through independent registry sources and DOI content negotiation. It does not directly access client attachments, conversation context, private filesystem paths, or proprietary attachment IDs. It does not create Zotero items, change a Zotero library, download papers, scrape publisher HTML, bypass paywalls, or claim that metadata means a paper was read.

flowchart LR
  A[MCP Client RAG Attachments] --> B[Extracted text sent to MCP tool]
  B --> C[Keyword and query analysis]
  C --> D[Crossref/OpenAlex/DataCite discovery]
  D --> E[Candidate ranking]
  E --> F[DOI validation]
  F --> G[Zotero exact DOI check when configured]
  G --> H[Validated reference metadata returned]

Related MCP server: sourceright

Quick start

docker build -t rag-reference-discovery-mcp:latest .
docker run --rm -i --env-file "C:\\MCP\\.env" rag-reference-discovery-mcp:latest

Public-only operation needs no Zotero credentials:

Copy-Item .env.example .env
# Leave ZOTERO_* values empty
docker run --rm -i --env-file .env rag-reference-discovery-mcp:latest

Compose:

Copy-Item .env.example .env
docker compose build
docker compose run --rm rag-reference-discovery-mcp

The default transport is stdio. stdout is reserved for MCP protocol messages; diagnostics are sent to stderr.

MCP client configuration

{
  "mcpServers": {
    "rag-reference-discovery": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "--env-file",
        "C:\\MCP\\.env",
        "rag-reference-discovery-mcp:latest"
      ]
    }
  }
}

Attachment handoff

The container cannot magically see attachments held by the MCP client. The client must extract the relevant text and pass it as source_text to analyze_research_text or discover_and_validate_references. source_name, source_type, section_hint, requirements, dates, and scope can be supplied as additional context. The resource tool is an explicit safe fallback: this standalone server returns attachment_content_unavailable unless a future MCP host adapter provides a standards-compliant readable resource context. It never fetches arbitrary URIs or local paths.

Tools

`analyze_research_text`

Input: source_text, optional source_name, source_type, section_hint, assignment_requirements, max_keywords, and max_queries. Returns a research profile, ranked explainable keywords, low-value terms, query variants, constraints, warnings, and source coverage.

Example:

{
  "source_text": "Compare Kubernetes and Docker container orchestration security in higher education between 2022 and 2026.",
  "source_type": "assignment_brief",
  "assignment_requirements": "Use peer-reviewed scholarly sources.",
  "max_keywords": 10
}

`analyze_attachment_resource`

Input: resource_uri and optional section_hint, requirements, and limits. Returns structured attachment_content_unavailable when no safe server-side resource adapter is present. Use direct extracted text for portable operation.

`discover_references`

Input: at least one of source_text, keywords, or queries, with optional publication years, work types, open-access filter, limits, relevance threshold, and validation mode. Returns discovered_candidates separately from any validated records. Discovery uses allowlisted scholarly metadata endpoints only.

`validate_reference`

Input: a raw DOI, doi: value, DOI URL, expected metadata, and options. It normalizes the DOI and independently checks Crossref, DataCite, OpenAlex, and DOI CSL-JSON content negotiation. Conflicting fields remain explicit.

Example:

{
  "doi_or_url": "https://doi.org/10.1000/example",
  "expected_title": "Example study",
  "prefer_zotero": true,
  "include_abstract": false
}

`discover_and_validate_references`

Input: source_text, optional requirements, date/type constraints, candidate and validation limits, relevance threshold, and Zotero preference. Runs analysis, discovery, ranking, and independent validation. It returns discovered candidates, validated references, and unresolved/rejected candidates separately. It is not a comprehensive literature review.

Example:

{
  "source_text": "Investigate reproducible Kubernetes security practices for universities from 2022 to 2026.",
  "publication_from_year": 2022,
  "publication_to_year": 2026,
  "max_validated_references": 5
}

`format_validated_reference`

Input: a validated reference object and one of apa, harvard, ieee, vancouver, chicago-author-date, bibtex, or csl-json. Only validated and partially_validated records are accepted. Missing fields stay missing.

`health`

Returns server version, enabled sources, non-secret Zotero configuration state, cache settings, supported ingestion modes, and stdio transport.

Zotero

Zotero is optional and read-only. Set ZOTERO_LOCAL_API_URL for an operator-configured local endpoint, or set ZOTERO_API_KEY, ZOTERO_LIBRARY_TYPE, and ZOTERO_LIBRARY_ID for optional Web API integration. Public discovery and registry validation work without Zotero. An exact normalized DOI match is a validation/enrichment check, never a discovery requirement. This release reports configuration and continues with independent registries; it never writes, saves, syncs, uploads, or deletes Zotero data.

Configuration

See .env.example for USER_AGENT, timeouts, retry and concurrency limits, source text and batch limits, metadata/search TTL cache settings, ranking weights, logging, and optional Zotero variables. Credentials are never emitted in health responses or logs. Attachment text and API keys are not persistently cached. Metadata cache defaults are 24 hours; search cache defaults are 1 hour; transient failures are not cached.

Security and privacy

Input text, terms, DOI values, and URLs are untrusted. The server uses bounded concurrency, explicit timeouts, allowlisted HTTPS hosts, conservative DOI parsing, and no arbitrary URL fetching. It rejects local/private hosts except an explicitly configured local Zotero endpoint. Retrieved metadata may be incomplete, inconsistent, or updated over time.

Limitations

Metadata coverage varies by publisher and DOI agency. RAG extraction quality affects keyword quality. Local lexical ranking is not expert literature review. DOI validation confirms metadata consistency, not scientific quality. Some valid works do not have DOIs. Zotero absence does not invalidate a DOI record. Review formatted output against institutional style requirements.

Troubleshooting

No candidates: supply more specific text or explicit keywords; inspect errors_by_source and throttling warnings.
Generic keywords: include the assignment's named technologies, population, method, period, and geography in source_text.
Invalid DOI: pass a raw DOI or https://doi.org/...; arbitrary publisher URLs are intentionally not scraped.
Throttling/timeouts: provide a descriptive contact USER_AGENT, reduce concurrency, and retry later.
Zotero not configured: public validation remains available; this is expected.
Zotero mismatch: exact DOI equality is required and registry conflicts are surfaced.
Docker stdin issues: use docker run --rm -i; do not allocate a TTY.
Invalid MCP configuration: use the stdio JSON configuration above and ensure the image is built locally.
Resource unavailable: pass extracted attachment text through source_text.

Development

Use uv for reproducible environments:

uv sync --extra dev
uv run ruff check .
uv run pytest
uv lock

CI runs Ruff and pytest on Python 3.12 with mocked/local tests only. No live scholarly API calls are required by the test suite.

Available Tools

7 tools

analyze_attachment_resourceC

Read a client-provided MCP resource when a standards-compliant resource adapter is available.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

TDQS

C2.2/5.0

Behavior2/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 indicates a read operation but says nothing about side effects, required permissions, failure modes, or return values. The adapter availability qualifier hints at a prerequisite but does not explain actual behavior.

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 with no fluff, front-loaded with the verb and resource. It is efficient in structure, though the brevity sacrifices necessary content. As a structure score, it earns credit for being concise and well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is severely inadequate for a tool with five parameters, no output schema, and no annotations. It does not explain what the tool does with the resource, how parameters affect behavior, or what the output will be. The conditional about adapter availability adds little context.

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%, so the description must compensate for the lack of parameter documentation. It does not mention any of the five parameters (resource_uri, max_queries, max_keywords, section_hint, assignment_requirements). The phrase 'client-provided MCP resource' weakly maps to resource_uri, but this is far from sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Read') and resource ('client-provided MCP resource'), but it omits the analysis aspect implied by the tool name and instead focuses on a conditional prerequisite (adapter availability). It does not clearly differentiate from sibling tools, though none seem to read attachment resources. The purpose is understandable but vague.

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 given on when to use this tool versus alternatives. The only condition mentioned is 'when a standards-compliant resource adapter is available', which is a prerequisite rather than a usage guideline. No exclusions or alternative tool references are provided.

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

analyze_research_textC

Analyze attachment-derived text into explainable scholarly search terms.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

TDQS

C2.7/5.0

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 behavioral burden. It only says 'analyze' and mentions 'explainable' output, but it does not disclose what processing occurs, whether external services are called, what happens with the input text, or how the 'explainable' aspect is delivered.

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 filler or repetition. It is front-loaded with the core action and output, though it is arguably too terse for a tool with many nested parameters.

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?

For a tool with seven nested parameters, no output schema, and no annotations, one sentence is insufficient. The description does not explain return values, parameter relationships, required source_type behavior, or what 'explainable' means in practice, leaving significant gaps for an agent.

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 vaguely maps to source_text via 'attachment-derived text'. None of the other parameters (max_queries, max_keywords, source_type, section_hint, assignment_requirements) are explained or even mentioned, so the agent receives almost no semantic help for them.

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 a specific action ('Analyze') on a specific resource ('attachment-derived text') with a defined output ('explainable scholarly search terms'). It does not explicitly distinguish it from the sibling tool analyze_attachment_resource, but the focus on text-to-search-terms gives enough differentiation.

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 about when to use this tool versus siblings like analyze_attachment_resource, discover_references, or validate_reference. No context is provided about which input types or workflows this tool is intended for beyond the vague 'attachment-derived text'.

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

discover_and_validate_referencesC

Analyze supplied RAG text, discover candidates, and validate the strongest matches.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only gives a high-level summary ('analyze', 'discover', 'validate') and does not mention potential side effects, external network calls, performance implications, read-only nature, or error behavior. An agent has no idea what happens during execution or what constraints exist, which is insufficient for a complex operation.

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 that front-loads the input ('supplied RAG text') and then lists the three main actions. It is efficient and has no fluff, though it sacrifices completeness for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex with 11 parameters, no output schema, and no annotations. The one-sentence description is grossly inadequate for an agent to understand how to configure the request, what the return value looks like, or when to use this tool. Almost all necessary context is missing.

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 coverage is 0% – the schema provides only names and defaults, no descriptions. The description does not mention any parameters or how they influence behavior. For a tool with 11 parameters, this is a critical gap; the description adds no semantic meaning beyond what the schema already shows.

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 tool's composite function: it analyzes supplied text, discovers candidates, and validates matches. The resource ('RAG text') and the actions are explicit, and the tool name confirms it deals with references. It distinguishes itself from the separate discover_references and validate_reference siblings by implying a combined end-to-end flow, though it does not name these alternatives.

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

Usage Guidelines3/5

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

The compound description implies the tool performs both discovery and validation, so an agent can infer it is appropriate when both steps are needed. However, there is no explicit guidance on when to use this versus the standalone siblings, nor any mention of exclusions or prerequisites. The usage context is only implied, not stated.

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

discover_referencesB

Discover and rank public scholarly metadata without claiming validation.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations at all, the description carries the full burden. It does disclose a meaningful behavioral trait: the tool does not validate metadata and merely ranks public scholarly output. However, it says nothing about return format, data sources, limitations, or side effects, leaving significant behavioral context undisclosed.

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 compact sentence that front-loads the core purpose and adds the validation caveat. Every word earns its place; there is no fluff or repetition.

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 the rich schema, this is a 14-parameter nested request tool with no annotations and no output schema. The one-sentence description covers only the high-level intent and lacks guidance on how to structure requests, interpret results, or choose validation-related options, so it is not fully adequate for correct invocation.

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 information about the nested request object or any of its 14 properties such as queries, validation_mode, max_results, or publication year filters. The agent is left to infer all parameter semantics from the raw JSON 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 uses a specific verb ('Discover and rank') and a specific resource ('public scholarly metadata'), and the caveat 'without claiming validation' clearly differentiates it from sibling validate_reference and discover_and_validate_references. An agent can tell this is a discovery-only tool even before examining the schema.

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

Usage Guidelines3/5

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

The phrase 'without claiming validation' implies this tool is for unvalidated discovery, but there is no explicit when-to-use or when-not-to-use guidance, nor is any sibling alternative named. Usage context is implied rather than stated.

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

format_validated_referenceC

Format only metadata that has an accepted validation status.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It adds a meaningful precondition ('accepted validation status') but does not disclose what happens for invalid/unaccepted metadata, what output is produced, whether the operation is read-only, or any 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused sentence with no redundant words. The key constraint is front-loaded, making it easy to parse quickly.

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?

For a tool with no annotationsable output schema custody and no annotations, the description is too sparse. It fails to specify what 'format' produces, which status values count as accepted, and how errors are handled. An agent would need to guess or inspect other 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%, and the description adds no parameter-level meaning for 'style' or 'include_doi_url'. It only loosely maps 'metadata' to the required 'validated_reference' property, leaving the agent to rely entirely on the schema for parameter behavior.

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 a specific verb ('Format') and a resource ('metadata that has an accepted validation status'), which clearly distinguishes it from validation/discovery siblings. It stops short of saying what formatting output looks like, but the core purpose is identifiable.

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

Usage Guidelines3/5

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

The phrase 'only metadata that has an accepted validation status' gives a clear precondition and implies this tool should follow validation. However, it does not explicitly name alternatives or state when to prefer another sibling tool.

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

healthA

Report non-secret server and integration configuration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It adds some useful context by specifying the report is non-secret and scoped to server/integration configuration, but it does not describe output format, side effects, or failure behavior.

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, front-loaded sentence with no filler. Every word adds meaning, particularly the 'non-secret' qualifier.

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?

For a zero-parameter, no-output-schema utility, the description is reasonably complete: it names the action, subject, and confidentiality constraint. It could add detail about what 'configuration' includes or what the response looks like, but complexity is low.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is trivially complete. The description has no parameter burden and still clarifies the subject matter of the report.

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 a specific verb ('Report') and a clear resource ('non-secret server and integration configuration'). It is clearly distinguished from the research-oriented sibling tools by domain and intent.

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 given about when to use this tool versus any alternative, nor are exclusions or prerequisites mentioned. The intended use case is only implied by the description.

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

validate_referenceC

Independently validate a DOI using public metadata registries.

ParametersJSON Schema

Name	Required	Description	Default
`request`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool uses public metadata registries and performs independent validation, but it does not disclose output shape, failure modes, network dependency, or how 'validation' is determined. This is a significant gap for a tool that performs external lookups.

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, front-loaded sentence with no filler. Every word adds meaning: 'independently' signals standalone operation, 'validate' states the action, 'DOI' gives the target, and 'public metadata registries' gives the source. It is as concise as possible.

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?

The tool has a nested request with seven propertiesament and no output schema or annotations, yet the description provides only a one-line summary. It does not explain what the validation result contains, how expected metadata is used, or when to prefer this tool over combined discovery+validation siblings. The surrounding context is too rich for this description to be considered complete.

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 for undocumented parameters. It clarifies that the input should be a DOI, but says nothing about expected_year, expected_title, expected_authors, prefer_zotero, include_abstract, or include_raw_source_summaries. These expected-value parameters are central to how validation works and are left 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 names a specific verb ('validate'), a resource ('a DOI'), and a method ('using public metadata registries'), making the primary action clear. It does not explicitly differentiate from sibling tools like discover_references or discover_and_validate_references, though 'independently' hints at standalone validation.

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 does not state when to use this tool versus siblings such as discover_references or discover_and_validate_references. No exclusions, preconditions, or alternative routing is given, leaving the agent to infer the intended context from the name alone.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.0Sep 16, 2026
- First observedanalyze_attachment_resource
- First observedanalyze_research_text
- First observeddiscover_and_validate_references
- First observeddiscover_references
- First observedformat_validated_reference
- First observedhealth
- First observedvalidate_reference

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-09-16 06:35 across 7 tools

Disambiguation4/5

Most tools map to distinct workflow stages, but analyze_research_text and analyze_attachment_resource share a similar 'analyze' prefix and discover_references vs discover_and_validate_references could cause some selection confusion. The descriptions mostly clear this up, so the overlap is minor.

Naming Consistency4/5

The set largely follows a clear verb_noun snake_case pattern, e.g. discover_references, validate_reference, format_validated_reference. 'health' is a bare noun and 'discover_and_validate_references' uses a compound verb, creating minor deviations from the dominant pattern.

Tool Count5/5

Seven tools is a well-scoped size for a reference discovery and validation server. Each tool supports a distinct part of the analyze-discover-validate-format workflow without unnecessary bloat.

Completeness5/5

The tool surface covers the full intended pipeline: extracting search terms, discovering references, validating DOIs, combining discovery and validation, and formatting results. The health tool also covers operational needs, and no critical workflow appears missing.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

academic-research-mcpOAuth
com.themineworks
Scholarly search: OpenAlex, Crossref, arXiv, OpenCitations and PubMed in one endpoint.
Search Research & Data Open Data
11
Papertext
app.papertext.app
Academic literature search, retrieval, and private library management on top of OpenAlex.
Search Research & Data Knowledge & Memory
2
crossref-mcp-server A
io.github.cyanheads
Resolve DOIs, search ~155M scholarly works, and fetch references via the Crossref REST API.
Research & Data Open Data
713
Scholar Sidekick A
io.github.mlava
Catch AI-fabricated citations (real DOI + fake title). Retraction, open-access, 10,000+ CSL styles.
Research & Data Open Data
719

Related MCP Servers

BibTeX MCP Server
Research & Data Search
xeophon
A
license
A
quality
D
maintenance
Searches academic references from arXiv, DBLP, Semantic Scholar, and OpenAlex concurrently and generates BibTeX citations.
Updated a year ago (2025-07-25 09:07 UTC)
4
11
MIT
sourceright
Research & Data Documentation Access
edithatogo
A
license
Not graded
quality
C
maintenance
reference and citation validation, verification, enrichment, replacement and improvement
Updated 2 days ago (2026-09-18 14:15 UTC)
1
MIT
Open Source Literature MCP
Research & Data AI & Machine Learning
simthw
F
license
B
quality
D
maintenance
Enables automatic literature discovery, screening, and ranking across OpenAlex, Semantic Scholar, and arXiv, with tools for exporting to Zotero and generating research ideas.
Updated 3 months ago (2026-06-18 07:39 UTC)
7
1
-
io.github.lonexreb/retractguar
Research & Data Open Data
lonexreb
A
license
A
quality
A
maintenance
Provides MCP tools to check reference lists for retracted or problematic citations, retrieve nuanced editorial statuses with evidence, and monitor institutions for newly flagged papers using open data from OpenAlex, Retraction Watch, and Crossref.
Updated 2 months ago (2026-07-16 17:54 UTC)
3
MIT