scifinder-route-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SCIFINDER_ROUTE_TOKEN | No | Legacy single token for authentication. If not set, use SCIFINDER_ROUTE_USERS. | |
| SCIFINDER_ROUTE_USERS | No | Multi-user token configuration in format user1:token1:role1,user2:token2:role2. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| register_documentB | Register and parse a local SciFinder export file already visible to the server. |
| upload_documentC | Copy a server-visible file into the upload area, then register and parse it. |
| scan_inboxB | Scan the NAS inbox for supported SciFinder exports and queue/register new files. |
| get_parse_job_statusC | Return parse job status, stage, and error details. |
| list_parse_jobsC | List recent parse jobs, optionally filtered by status. |
| health_checkB | Return server health, configured paths, and indexed object counts. |
| get_configA | Return the effective application config. Secrets are masked unless include_secrets is true. |
| update_configB | Merge hot-reloadable application config updates into config.yaml and reload them. |
| validate_configB | Validate the current application config and report settings that require container restart. |
| reload_configB | Reload hot application config from config.yaml without restarting the container. |
| search_reaction_stepsB | Search extracted reaction steps by text and structured condition filters. |
| get_reaction_stepC | Return one structured reaction step. |
| get_reaction_provenanceC | Return source text/page/parser provenance for a reaction step. |
| reparse_documentC | Clear extracted reactions for a document and parse it again. |
| record_doi_verificationC | Record DOI source verification performed by an agent or browser workflow. |
| export_evaluation_setC | Export extracted reaction steps as JSONL for manual labeling and regression checks. |
| retry_parse_jobB | Retry a failed or completed parse job by moving it back to the durable queue. |
| retry_failed_jobsC | Retry recent failed parse jobs. |
| rebuild_vector_indexC | Generate embeddings for reaction steps using the configured embedding endpoint. |
| get_vector_index_statusB | Return vector index coverage, model, and last error. |
| semantic_search_reaction_stepsC | Search reaction steps semantically using the configured embedding endpoint. |
| search_compoundsB | Search the compound registry by name, CAS, SMILES, or InChIKey. |
| get_compoundC | Return compound metadata, aliases, and linked reactions. |
| merge_compoundsB | Merge source compound aliases/reaction links into a target compound. |
| search_by_smilesB | Normalize a SMILES string when RDKit is available, then search compounds. |
| recognize_structure_imageC | Send an image region to a configured MolScribe/DECIMER/OSRA-style endpoint and register candidate SMILES. |
| compute_evaluation_metricsC | Compute regression metrics from a gold-set JSONL file. |
| get_evaluation_statusC | Return the latest evaluation metrics. |
| backup_databaseC | Create a SQLite database backup, or report Postgres backup guidance. |
| get_storage_usageC | Return NAS data/upload/evidence storage usage. |
| cleanup_evidence_cacheC | Clean generated evidence/cache files without deleting source documents. |
| test_integration_endpointB | Test one configured integration endpoint: llm, embedding, ocr, document_parser, structure_recognition, postgres. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 32 tools
Each tool has a specific, well-defined purpose. Document ingestion, compound/reaction searching, evaluation, and config/health tools are clearly separated without overlap. An agent can easily distinguish between e.g., search_compounds and search_by_smiles, or between list_parse_jobs and get_parse_job_status.
All tool names follow a consistent snake_case verb_noun pattern (e.g., backup_database, get_compound, search_reaction_steps). There is no mixing of cases or inconsistent verb forms, making the naming predictable and clear.
With 32 tools, the set is too large for typical MCP server coherence. While the domain is complex, many tools could be consolidated (e.g., multiple get_ and search_ tools). The count exceeds the 25+ threshold for 'too many' and may overwhelm agents.
The tool surface covers the full lifecycle: document ingestion, parsing, compound/reaction search, evaluation, config management, and maintenance. Minor gaps exist (e.g., no explicit delete for documents or compounds), but core workflows are well-supported and no dead ends are apparent.