mcp-sparkit
Officialsparkit-mcp
MCP-Server für SPARKIT — rufen Sie den wissenschaftlichen Forschungsagenten aus Claude Desktop, Cursor, Claude Code oder einem anderen MCP-kompatiblen Client auf.
Zwei Tools werden bereitgestellt:
research— eine wissenschaftliche Frage einreichen. SPARKIT durchsucht die Literatur, liest die relevanten Arbeiten und gibt einen zitierten Markdown-Bericht zurück. Blockiert, bis der Auftrag abgeschlossen ist (Standard 4 Min.), und gibt den vollständigen Bericht inline zurück.get_job_status— einen zuvor eingereichten Auftrag anhand der ID abrufen. Nützlich, wennresearchzurückkehrte, bevor der Auftrag abgeschlossen war, oder um einen früheren Bericht erneut aufzurufen.
Installation
uv tool install sparkit-mcpOder mit pip:
pip install sparkit-mcpBeides installiert ein sparkit-mcp-Konsolenskript. (Vorabversion: Installieren Sie direkt von GitHub mit
uv tool install "git+https://github.com/SPARKIT-science/sparkit-mcp.git"
bis die erste PyPI-Version erscheint.)
Related MCP server: pubmed-search-mcp
API-Schlüssel erhalten
Registrieren Sie sich unter https://app.sparkit.science/signup (Try-it kostet 10 $ für 5 Abfragen; Abonnements beginnen bei 50 $/Monat).
Besuchen Sie https://app.sparkit.science/keys und erstellen Sie einen Schlüssel.
Kopieren Sie den Schlüssel — er wird nur einmal angezeigt.
Konfigurieren Sie Ihren MCP-Client
Claude Desktop
Bearbeiten Sie claude_desktop_config.json:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Fügen Sie hinzu:
{
"mcpServers": {
"sparkit": {
"command": "sparkit-mcp",
"env": {
"SPARKIT_API_KEY": "sk_sparkit_..."
}
}
}
}Starten Sie Claude Desktop neu. Sie sollten sparkit im Tool-Symbol neben der Chateingabe sehen.
Wenn sparkit-mcp nicht im PATH von Claude Desktop enthalten ist (häufig bei uv tool), verwenden Sie den absoluten Pfad:
"command": "/Users/you/.local/bin/sparkit-mcp"(Finden Sie den Pfad mit which sparkit-mcp nach uv tool install.)
Cursor
Bearbeiten Sie ~/.cursor/mcp.json (oder .cursor/mcp.json in Ihrem Projekt):
{
"mcpServers": {
"sparkit": {
"command": "sparkit-mcp",
"env": {
"SPARKIT_API_KEY": "sk_sparkit_..."
}
}
}
}Laden Sie Cursor neu (Cmd+Shift+P → "Reload Window").
Claude Code
claude mcp add sparkit -e SPARKIT_API_KEY=sk_sparkit_... -- sparkit-mcpAusprobieren
Fragen Sie nach der Konfiguration das LLM:
Verwende SPARKIT, um die aktuellste Literatur zur Rolle von WRNIP1 als synthetisch-letales Ziel bei Krebs zu recherchieren.
Das LLM ruft research auf. Erwarten Sie eine Wartezeit von 60-180 Sekunden, gefolgt von einem Markdown-Bericht mit Inline-Zitaten und einer nummerierten Quellenliste.
Konfiguration
Umgebungsvariable | Standard | Beschreibung |
| (erforderlich) | Bearer-Schlüssel von https://app.sparkit.science/keys. |
|
| Überschreiben der API-Basis-URL. Nützlich für Staging oder selbst gehostete Bereitstellungen. |
|
| Timeout pro HTTP-Anfrage. Beeinflusst nicht die Gesamtwartezeit für |
Tool-Referenz
research(question, response_format?, include_citations?, max_wait_seconds?)
Argument | Typ | Standard | Beschreibung |
| string | — | Die wissenschaftliche Frage. Erforderlich. Seien Sie spezifisch. |
|
|
| Länge des zurückgegebenen Markdown-Berichts. |
| boolean |
| Auf |
| int (30-540) |
| Wie lange gewartet werden soll, bevor die job_id mit Anweisungen zum Abrufen zurückgegeben wird. |
Gibt Markdown zurück. Bei einem Timeout wird eine Statuszeile mit der job_id zurückgegeben, damit das LLM später get_job_status aufrufen kann.
get_job_status(job_id)
Gibt den zitierten Markdown-Bericht zurück, wenn der Auftrag abgeschlossen ist, eine Statuszeile, wenn er noch läuft, oder andernfalls eine Fehlermeldung.
Fehlerbehebung
Authentifizierung fehlgeschlagen — SPARKIT_API_KEY ist nicht gesetzt oder ungültig. Überprüfen Sie claude_desktop_config.json auf Tippfehler; starten Sie Claude Desktop nach Änderungen neu.
Kontingent erschöpft — keine monatlichen Abfragen / Try-it-Guthaben mehr verfügbar. Besuchen Sie https://app.sparkit.science/billing.
Tool erscheint nicht in Claude Desktop — überprüfen Sie das Claude Desktop-Protokoll:
macOS:
~/Library/Logs/Claude/mcp-server-sparkit.logWindows:
%LOCALAPPDATA%\Claude\Logs\mcp-server-sparkit.log
Das häufigste Problem ist, dass command: sparkit-mcp nicht im PATH ist; ersetzen Sie es durch den absoluten Pfad von which sparkit-mcp.
Auftrag läuft ab (Timeout) — das Limit für max_wait_seconds beträgt 540s (9 Min.). Bei sehr tiefgreifenden Fragen reichen Sie den Auftrag ein und rufen Sie dann get_job_status ab, anstatt inline zu warten. SPARKIT bricht Aufträge, die sein eigenes internes Limit überschreiten, ebenfalls automatisch ab.
Lizenz
MIT.
Available Tools
2 toolsget_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.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| response_format | No | full | |
| include_citations | No | ||
| max_wait_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v0.1.0- First observed
get_job_status - First observed
research
TDQS
Scored across 2 tools
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.
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.
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.
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
Related MCP Connectors
Open scientific and engineering knowledge for AI agents: search, evidence, document publishing.
Search peer-reviewed papers and research methodology guidance from your AI agent.
Ground answers in scientific literature. Search full text, evaluate trust, access full-text articles
Search 8.5M scientific papers with LLM TLDRs, citations, linked entities, figures, and full text.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceTurn any AI agent into an academic researcher that can search, read, cite, and write full literature reviews autonomously.14MIT
- AlicenseAqualityBmaintenanceAn intelligent research assistant MCP server for AI agents, providing task-oriented literature search and analysis across multiple academic databases.41230 PyPI28Apache 2.0
- AlicenseNot gradedqualityFmaintenanceEnables AI agents to search academic papers, analyze citations and authors, track trending research, and find semantically related work using free scholarly sources.MIT
- AlicenseNot gradedqualityDmaintenanceEnables scientific literature research through multi-agent search, analysis, and semantic memory, exposing 9 MCP tools for querying, storing, and retrieving research findings.1MIT