synthia-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| inspect_environmentA | Report Python and Synthesizer environment facts. Synthesizer is never imported here, so this is cheap and has no side
effects. The price is being honest about what was checked:
Returns:
A mapping with |
| inspect_synthesizer_apiA | Look up a public Synthesizer object by dotted name. Resolves a name such as Side effects: this imports Synthesizer. The first call in a process
takes roughly 1.7-2.0 seconds and runs Names are restricted: at most 200 characters and 8 dot-separated
segments, every segment a plain identifier that is neither a Python
keyword nor prefixed with an underscore, and the first segment
exactly Args:
dotted_name: Public dotted path rooted at Returns:
On success a mapping with |
| list_local_gridsA | List the Synthesizer grid files available on this machine. Reports the resolved grid directory and the grid files inside it without opening any of them, so an agent can pick a grid before paying to inspect it. Importing Synthesizer takes a couple of seconds and creates its data directories as a side effect. Returns:
On success, a mapping with |
| inspect_local_gridA | Describe a local Synthesizer grid: axes, model, and contents. Loads the grid's metadata only (no spectra or lines) and lists the groups and datasets the file holds, so an agent can tell what spectra, extinction curves, or lines are available before loading anything. Dataset values are never read apart from the identifiers naming a grid's emission lines, and links are never followed. Importing Synthesizer takes a couple of seconds and creates its data directories as a side effect. Args:
grid_name: Name of a grid in the local grid directory, with or
without an Returns:
On failure, a mapping with |
| search_catalogueA | Search the Syndex catalogue of published Synthesizer datasets. Syndex is the project's data service: every grid, instrument and
test dataset the project publishes is listed there. Use this to
answer "which grids exist?", "is there a BPASS grid with lines?" or
"what could I download?" — it reports what is published, not what is
installed here. Use Requires network access. Nothing is downloaded: the result carries
the Args:
query: Free-text filter. Every whitespace-separated term must
appear somewhere in a dataset's name, display name,
description or type, case-insensitively.
data_type: Restrict to one catalogue type, such as Returns:
On failure, a mapping with |
| describe_catalogue_datasetA | Describe one published dataset in the Syndex catalogue. Reports what a Syndex dataset's current release contains — for a
grid, its axes and their extent, which spectra and emission lines it
holds, the model it came from and how to cite it — without
downloading the file. This is how to answer "does the published
BPASS grid cover Z = 1e-5?" or "which lines would I get?" for a grid
that is not installed here. Use Requires network access. Names come from Args:
name: Catalogue dataset name, such as
Returns:
On failure, a mapping with |
| list_catalogue_releasesA | List every published release of one Syndex dataset. Releases are immutable: a regenerated or corrected file is published as a new release and the old one stays resolvable. Use this to see which versions exist, which is current, which carry a known bug, and which Synthesizer versions a release is declared to work with — before pinning a download to one. Requires network access. Args:
name: Catalogue dataset name, as listed by Returns:
On failure, a mapping with |
| search_documentationA | Search the bundled skill tree and any Synthesizer checkout docs. Args: query: Words to look for. Matching is plain substring and token matching, not a query language. Returns:
A mapping with |
| find_exampleA | Find the closest canonical example for a task. Args: task: Short description of what the user wants to do. Returns:
A mapping with |
| validate_scriptA | Statically validate a Synthesizer script. The script is parsed, never run. Checks run least invasive first: syntax, import availability by specification lookup only, referenced Synthesizer attributes and keyword arguments, and locally available grids. Args: source: Python source text. Returns:
A mapping with |
| plot_grid_spectraA | Plot a local grid's spectra at one grid point. Renders the spectra a grid holds at a chosen point, so the shape of
the grid's output can be seen without writing a script. Loading
spectra reads the full arrays, so this is slower than
Args:
grid_name: Grid name, with or without a file suffix.
spectra_types: Spectra to draw, defaulting to every spectrum the
grid provides, capped at six.
point: Axis name to value, each in that axis's own units, for
example Returns:
A mapping with |
| plot_grid_linesA | Plot the emission lines a local grid holds at one grid point. Args:
grid_name: Grid name, with or without a file suffix.
point: Axis name to value in that axis's own units, defaulting
to the centre of the grid.
line_ids: Lines to draw, for example Returns:
A mapping with |
| plot_grid_ionising_luminosityA | Plot a grid's specific ionising luminosity over its axes. This is the standard diagnostic for whether a grid covers the ionising output a study needs. Args:
grid_name: Grid name, with or without a file suffix.
ion: Ion to plot, one of Returns:
A mapping with |
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 13 tools
Most tools are clearly distinct: search vs list vs inspect vs plot families each target different resources and actions. Minor overlap exists between search_documentation and find_example for how-to questions, and the three plot_grid_* tools share a prefix but are differentiated by what they render.
Tool names follow a mostly consistent verb_noun snake_case pattern (search_, list_, inspect_, plot_, describe_, validate_). The main inconsistency is using 'find' vs 'search' for similar lookup actions and 'describe' vs 'inspect' for catalogue vs local metadata, but the pattern remains readable and predictable.
13 tools is well-scoped for a server covering documentation search, examples, catalogue browsing, local grid inspection/plotting, environment/API inspection, and script validation. Each tool has a clear role and none feel redundant or like filler.
The tool surface covers the main workflows: finding docs/examples, discovering and describing catalogue datasets, listing and inspecting local grids, plotting grid outputs, inspecting the environment/API, and validating scripts. Minor gaps exist, such as no tool to return raw spectral/line data as structured values rather than plots, but these are workable limitations rather than dead ends.