mathlib-mcp
Server 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 |
|---|---|
| search_apiA | Search CuPy / nvmath-python APIs (cuBLAS, cuFFT, cuSOLVER, cuSPARSE, cuDSS, cuTENSOR) by task description or name, e.g. "batched least squares" or "rfft". |
| get_api_cardA | Get the exact signature, parameters, return value, pitfalls and a GPU-verified example for one function or class, e.g. "cupyx.scipy.sparse.linalg.cg". |
| get_exampleA | Get runnable, GPU-verified example code (with pitfalls) for the curated APIs most relevant to a task, e.g. "matmul with bias and relu epilog". |
| check_snippetA | Statically check Python code that uses CuPy / nvmath-python without running it: reports functions, modules and enum members that do not exist (with the closest real names), unknown or positional-only keyword arguments, too many positional arguments and missing required arguments. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| llms.txt | Index of all API cards (llms.txt format). |
TDQS
Scored across 4 tools
Each tool has a fairly distinct role: search_api discovers APIs by task/name, get_api_card details one exact name, get_example returns task-based example code, and check_snippet validates user code. The main overlap is between search_api and get_example, since both accept a task description and surface relevant APIs/examples, but the distinction (discovery vs. runnable example) is workable.
All four tools follow a clean, predictable verb_noun snake_case pattern (search_api, get_api_card, get_example, check_snippet). No mixed conventions or vague verbs; names clearly signal the action.
Four tools is well-scoped for a focused API-assistant server, covering the natural workflow of discover, inspect, exemplify, and validate. Each tool earns its place with no redundant surface.
The surface covers discovery, detail, examples, and static validation, which handles the core code-writing lifecycle for CuPy/nvmath-python. Minor gaps exist, such as no way to browse/list a module's full API set or check multiple snippets, but agents can work around these via search.