Science MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SCIENCE_API_URL | No | Set SCIENCE_API_URL to use another API base, such as a local Science instance. The default is https://science.ecosyste.ms/api/v1. | https://science.ecosyste.ms/api/v1 |
| SCIENCE_SEEDS_DB | No | Set SCIENCE_SEEDS_DB only if you want lookup_software to read a fixed SQLite export instead of the API. Search and context tools still use the live API. A configured but missing or invalid file returns an error instead of switching sources. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| lookup_softwareB | Find exact software names or identifiers using Science's API. No local database is needed. API results group matching evidence by project; follow next_after_id with the same query and kind. Names are case insensitive. If SCIENCE_SEEDS_DB is set, use that snapshot instead: results are evidence rows and its cursor is a row ID. Keep the same source throughout pagination. |
| search_softwareA | Search Science for names containing at least three characters. Searches project names, aliases and published package names. Results contain matching evidence grouped by project, not relevance or confidence scores. Follow next_after_id with the same query. Always uses the live API. |
| list_seed_projectsA | Read one small page from Science's live seed API. This browses the catalogue; it does not search names. Follow next_page with the same per_page. Live pagination is not a frozen snapshot. |
| get_project_contextA | Read live Science context for one project. Summary returns descriptions, languages and counts. Choose packages or direct_dependencies for paginated details. Empty dependencies with a null indexing timestamp mean unknown coverage. Dependencies belong to the project, not necessarily to every package it publishes. Inspect truncations for omitted text. |
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 4 tools
search_software (substring/name search) and lookup_software (exact name or identifier) both retrieve software and could momentarily be confused, but the descriptions clearly distinguish fuzzy name search from exact lookup. list_seed_projects (catalogue browsing) and get_project_context (single-project detail retrieval) are clearly distinct.
All four tools follow a consistent snake_case verb_noun pattern: search_software, lookup_software, list_seed_projects, get_project_context. The verbs are predictable and map cleanly to their operations.
Four tools is a lean but reasonable set for a read-only discovery/lookup service covering search, exact lookup, catalogue listing, and project detail. It is slightly thin but each tool earns its place with a distinct operation.
The surface covers the main lifecycle of a catalogue server: discovery via search/lookup, browsing via seed listing, and detail retrieval via context. It lacks any cross-cutting query or export operation, but for a read-oriented search/lookup domain the core workflows are covered.