PyLops-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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_versionsA | List the PyLops and PyProximal versions that have an index. For each package the latest version is the default. |
| searchA | Search PyLops and PyProximal by name or docstring summary. kind is one of "all", "operator", "solver", "workflow" (PyLops) or "proxoperator", "proxsolver" (PyProximal). pylops_version and pyproximal_version select the versions (e.g. "2.6", "0.10"); default is the latest. |
| list_operatorsA | List operator names, optionally filtered by module (e.g. "basicoperators"). pylops_version selects the PyLops version (e.g. "2.6"); default is the latest. |
| list_solversA | List solver names, optionally filtered by module (e.g. "sparsity"). pylops_version selects the PyLops version (e.g. "2.6"); default is the latest. |
| list_workflowsB | List workflow names (inversion/decomposition helpers), optionally by module. pylops_version selects the PyLops version (e.g. "2.6"); default is the latest. |
| get_operatorB | Get signature, parameters, notes and examples of a PyLops operator. pylops_version selects the PyLops version (e.g. "2.6"); default is the latest. |
| get_solverB | Get signature, parameters, notes and examples of a PyLops solver. pylops_version selects the PyLops version (e.g. "2.6"); default is the latest. |
| get_workflowA | Get signature, parameters, notes and examples of a PyLops workflow. pylops_version selects the PyLops version (e.g. "2.6"); default is the latest. |
| list_proxperatorsA | List PyProximal proximal operator names, optionally filtered by module. pyproximal_version selects the PyProximal version (e.g. "0.10"); default is the latest. |
| list_proxsolversA | List PyProximal solver names, optionally filtered by module (e.g. "primal"). pyproximal_version selects the PyProximal version (e.g. "0.10"); default is the latest. |
| get_proxoperatorB | Get signature, parameters, notes and examples of a PyProximal operator. pyproximal_version selects the PyProximal version (e.g. "0.10"); default is the latest. |
| get_proxsolverB | Get signature, parameters, notes and examples of a PyProximal solver. pyproximal_version selects the PyProximal version (e.g. "0.10"); default is the latest. |
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 12 tools
Most tools are clearly distinct by resource and action (list vs get), and descriptions name the owning package. However, near-identical pairs like get_solver/get_proxsolver and list_solvers/list_proxsolvers require the agent to read carefully to avoid picking the PyLops tool when a PyProximal one is needed, and search overlaps slightly with the list/get pairs as an alternate discovery path.
The dominant pattern is a clean verb_noun scheme (list_operators, get_operator, list_workflows, get_solver). Minor deviations exist: the bare verb 'search', and the inconsistent prox prefix spelling between list_proxperators and get_proxoperator, which weakens predictability slightly.
Twelve tools is well within the sweet spot and every tool earns its place, reflecting a tidy symmetric surface (list+get for operators, solvers, workflows; list+get for proxoperators and proxsolvers; plus search and list_versions). No redundant or filler tools.
For a documentation-lookup server over two packages, the surface covers discovery (list per category, filtered by module), detail retrieval (get with signatures/params/examples), cross-cutting search, and version enumeration. There are no obvious dead ends an agent would hit.