Skip to main content
Glama
deenesjakoruzh
SPARKIT-science

mcp-sparkit

Official
by SPARKIT-science
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

sparkit-mcp

SPARKIT 的 MCP 服务器 —— 可从 Claude Desktop、Cursor、Claude Code 或任何其他兼容 MCP 的客户端调用科学研究智能体。

提供了两个工具：

  • research — 提交一个科学问题。SPARKIT 会搜索文献、阅读相关论文，并返回一份带有引用的 Markdown 报告。该工具会阻塞直到任务完成（默认 4 分钟）并直接返回完整报告。

  • get_job_status — 通过 ID 获取之前提交的任务。当 research 在任务完成前返回，或者需要重新查看过往报告时非常有用。

安装

uv tool install sparkit-mcp

或者使用 pip：

pip install sparkit-mcp

以上任一方式都会安装 sparkit-mcp 控制台脚本。（预发布版本：在第一个 PyPI 版本发布之前，请直接从 GitHub 安装： uv tool install "git+https://github.com/SPARKIT-science/sparkit-mcp.git"）

Related MCP server: pubmed-search-mcp

获取 API 密钥

  1. 在 https://app.sparkit.science/signup 注册（试用版 10 美元可进行 5 次查询；订阅费用每月 50 美元起）。

  2. 访问 https://app.sparkit.science/keys 并创建一个密钥。

  3. 复制该密钥 —— 它仅显示一次。

配置您的 MCP 客户端

Claude Desktop

编辑 claude_desktop_config.json：

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

添加：

{
  "mcpServers": {
    "sparkit": {
      "command": "sparkit-mcp",
      "env": {
        "SPARKIT_API_KEY": "sk_sparkit_..."
      }
    }
  }
}

重启 Claude Desktop。你应该会在聊天输入框旁边的工具图标中看到 sparkit。

如果 sparkit-mcp 不在 Claude Desktop 的 PATH 中（使用 uv tool 时常见），请使用绝对路径：

"command": "/Users/you/.local/bin/sparkit-mcp"

（在运行 uv tool install 后，使用 which sparkit-mcp 查找路径。）

Cursor

编辑 ~/.cursor/mcp.json（或项目中的 .cursor/mcp.json）：

{
  "mcpServers": {
    "sparkit": {
      "command": "sparkit-mcp",
      "env": {
        "SPARKIT_API_KEY": "sk_sparkit_..."
      }
    }
  }
}

重新加载 Cursor（Cmd+Shift+P → “Reload Window”）。

Claude Code

claude mcp add sparkit -e SPARKIT_API_KEY=sk_sparkit_... -- sparkit-mcp

尝试一下

配置完成后，询问 LLM：

使用 SPARKIT 查找关于 WRNIP1 作为癌症合成致死靶点的最新文献。

LLM 将调用 research。预计等待 60-180 秒，然后会收到一份带有内联引用和编号来源列表的 Markdown 报告。

配置

环境变量

默认值

描述

SPARKIT_API_KEY

(必填)

来自 https://app.sparkit.science/keys 的 Bearer 密钥。

SPARKIT_API_BASE

https://jlsteenwyk--sparkit-api-web.modal.run

覆盖 API 基础 URL。适用于暂存环境或自托管部署。

SPARKIT_API_TIMEOUT_SECONDS

30

每个 HTTP 请求的超时时间。不影响 research 的总等待时间；总等待时间由 max_wait_seconds 控制。

工具参考

research(question, response_format?, include_citations?, max_wait_seconds?)

参数

类型

默认值

描述

question

string

—

科学问题。必填。请具体说明。

response_format

"full" 或 "brief"

"full"

返回的 Markdown 报告长度。

include_citations

boolean

true

保持 true 以获取带来源的报告。

max_wait_seconds

int (30-540)

240

在返回 job_id 并提示轮询之前，阻塞等待的时长。

返回 Markdown。如果超时，将返回包含 job_id 的状态行，以便 LLM 稍后调用 get_job_status。

get_job_status(job_id)

如果任务已完成，返回带引用的 Markdown 报告；如果仍在运行，返回状态行；否则返回错误消息。

故障排除

身份验证失败 — SPARKIT_API_KEY 未设置或无效。检查 claude_desktop_config.json 是否有拼写错误；编辑后重启 Claude Desktop。

配额耗尽 — 每月查询次数/试用额度用尽。访问 https://app.sparkit.science/billing。

工具未在 Claude Desktop 中显示 — 检查 Claude Desktop 日志：

  • macOS: ~/Library/Logs/Claude/mcp-server-sparkit.log

  • Windows: %LOCALAPPDATA%\Claude\Logs\mcp-server-sparkit.log

最常见的问题是 command: sparkit-mcp 不在 PATH 中；请替换为 which sparkit-mcp 得到的绝对路径。

任务超时 — max_wait_seconds 上限为 540 秒（9 分钟）。对于非常深入的问题，请提交后轮询 get_job_status，而不是在线等待。SPARKIT 也会自动取消超过其内部限制的任务。

许可证

MIT。

Available Tools

2 tools
get_job_statusA

Fetch the current status (and result if done) of a SPARKIT job.

Use this when research returned before the job finished, or to revisit a previous result by id.

Args: job_id: The id returned by a prior research call.

Returns the cited Markdown report if the job has completed, a status line if it's still running, or a failure message otherwise.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

Describes return outcomes (completed report, running status, failure message). No annotations, but behavior is well-covered. Lacks explicit statement of non-destructiveness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Concise, front-loaded, each sentence adds value. Structured into purpose, usage, argument, returns. No wasted words.

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

Completeness5/5

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

Covers all necessary aspects for a simple tool: usage, parameter, return behavior. Output schema exists, so description suffices.

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 description explains job_id as 'The id returned by a prior `research` call', adding meaning beyond schema's title 'Job Id'. Schema coverage 0%, so description compensates.

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

Purpose5/5

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

Clearly states 'Fetch the current status (and result if done) of a SPARKIT job', specifying verb and resource. Distinguishes from sibling 'research' by context.

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

Usage Guidelines5/5

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

Explicitly says 'Use this when `research` returned before the job finished, or to revisit a previous result by id', providing clear when-to-use and alternative.

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

researchA

Submit a scientific question to the SPARKIT research agent.

SPARKIT searches the literature, reads relevant papers, and returns a cited Markdown report. Best for questions where a correct answer requires synthesizing across multiple primary sources.

Args: question: Free-text scientific question. Be specific — "Which kinases are upregulated in pancreatic cancer with evidence from human tissue?" works better than "tell me about pancreatic cancer." response_format: "full" (default) for a multi-paragraph Markdown report, or "brief" for a tighter summary. include_citations: Keep True (default) so the report is usable for downstream work; only set False if you specifically want unsourced prose. max_wait_seconds: How long to block waiting for the job before returning the job_id with instructions to poll via get_job_status. Default 240s (4 min). Range 30-540.

Returns the cited Markdown report on success. If the job is still running at the wait limit, returns the job_id and status so the caller can resume with get_job_status.

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYes
response_formatNofull
include_citationsNo
max_wait_secondsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

Despite no annotations, the description discloses key behaviors: async execution with timeout (max_wait_seconds), return types (inline report vs job_id), and parameter defaults. Could add rate limits or error handling, but overall thorough.

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?

Well-structured: concise opening, contextual paragraph, bullet-like Args section, and return value explanation. Every sentence adds value without redundancy.

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?

Covers input, usage, return types, and sibling relationship. Missing explicit error scenarios, but output schema likely covers that. Overall very complete for a complex async tool.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by explaining each parameter in detail: question specificity, response_format options, include_citations rationale, and max_wait_seconds range and purpose.

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 submits a scientific question to the SPARKIT research agent, which searches literature and returns a cited Markdown report. It distinguishes from sibling 'get_job_status' by describing async behavior and polling instructions.

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

Usage Guidelines5/5

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

Explicitly says 'Best for questions where a correct answer requires synthesizing across multiple primary sources.' Provides context on when to use, and mentions alternative polling via get_job_status.

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.

  1. 2 tool updatesv0.1.0
    • First observedget_job_status
    • First observedresearch
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

A4.5/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: 'research' submits a scientific question and returns either a report or a job ID, while 'get_job_status' retrieves the status or result of a previously submitted job. There is no overlap in functionality.

Naming Consistency4/5

Both tool names use snake_case, but 'research' is a single-word noun while 'get_job_status' follows a verb_noun pattern. This minor inconsistency prevents a perfect score.

Tool Count4/5

With only two tools, the server covers the essential workflow of submitting a research job and checking its status. While minimal, the count is appropriate for the narrow scope of a scientific research agent.

Completeness3/5

The tool set covers the primary use case (submit and retrieve results), but lacks features like job listing, cancellation, or retry. For a simple agent this may suffice, but there are notable gaps in lifecycle management.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers