Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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".

    Args:
        query: What the code needs to do, or part of a function name.
        library: Optional prefix filter such as "cupy", "cupyx.scipy.sparse" or "nvmath".
        limit: Maximum number of results (1-20).
    
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".

    Args:
        name: Fully qualified dotted name.
    
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".

    Args:
        task: Short description of what the code should do.
    
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.

    Args:
        code: Python source code.
    

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
llms.txtIndex of all API cards (llms.txt format).

TDQS

A3.9/5.0

Scored across 4 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues