vsponeblock-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VSPONEBLOCK_URL | Yes | Address of the REST API server, e.g. https://192.0.2.10. /ConfigurationManager is added unless the URL already ends with it. | |
| VSPONEBLOCK_SPEC | No | Path to a different OpenAPI file, YAML or JSON, e.g. for another microcode release (default is the bundled spec) | |
| VSPONEBLOCK_USER | Yes | Storage system user | |
| VSPONEBLOCK_CA_CERT | No | PEM file of the CA that signed the storage system's certificate | |
| VSPONEBLOCK_EXAMPLES | No | Example user questions per operation, used to rank search results. Set to an empty string to turn them off. | spec/examples.json |
| VSPONEBLOCK_PASSWORD | Yes | That user's password | |
| VSPONEBLOCK_TOOLSETS | No | Comma-separated API areas (tags) to expose as direct tools. all exposes all 425, which is not recommended. | |
| VSPONEBLOCK_TIMEOUT_MS | No | Request timeout; uploads are exempt | 120000 |
| VSPONEBLOCK_UPLOAD_DIR | No | Only allow uploads from inside this folder (default is any non-hidden path) | |
| VSPONEBLOCK_ALLOW_WRITES | No | Allow operations that change the storage system | false |
| VSPONEBLOCK_DECISION_LOG | No | Path to a JSON Lines file. When set, each search, describe and call is logged locally (operation names and argument names only, never values or credentials), for improving search. | |
| VSPONEBLOCK_DOWNLOAD_DIR | No | Where binary downloads and save_to files are written | ~/Downloads/vsponeblock-mcp |
| VSPONEBLOCK_INSECURE_TLS | No | Skip TLS verification (lab use only) | false |
| VSPONEBLOCK_PATH_REWRITES | No | Path prefixes to rewrite, as comma-separated /from=/to pairs, for an API served behind a gateway under another prefix | |
| VSPONEBLOCK_SAVE_ANYWHERE | No | Let save_to write outside VSPONEBLOCK_DOWNLOAD_DIR | false |
| VSPONEBLOCK_MAX_RESPONSE_CHARS | No | Truncation limit for text responses | 60000 |
| VSPONEBLOCK_SESSION_ALIVE_TIME | No | Session idle timeout to ask for, 1–300 seconds | 300 |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vsponeblock_list_operationsA | Browse the VSP One Block REST API. With no arguments, lists the API areas (tags) and how many operations each has. With |
| vsponeblock_describe_operationA | Show everything needed to call one VSP One Block operation: method and path, required permissions and prerequisites, parameters, request body schema and response schema. |
| vsponeblock_call_operationA | Call any VSP One Block REST API operation by operationId. Authentication is handled automatically. Pass path, query and header parameters by name in |
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 3 tools
The three tools map to a clean discover → inspect → invoke pipeline (list, describe, call), each with an unambiguous role and no overlap. The descriptions even instruct the intended ordering, making misselection unlikely.
All tools share the vsponeblock_ prefix and a verb_noun pattern (describe_operation, list_operations, call_operation). The only nit is singular/plural inconsistency between 'operation' and 'operations', which is minor and readable.
This is a gateway/proxy pattern exposing an entire REST API, so three tools is exactly the right scope rather than a thin surface. Each tool earns its place and adding more would only fragment the discovery flow.
The set fully covers the read-only lifecycle: browse areas, list operations, inspect schemas, and invoke any operation, including async job and binary-response handling. Write operations are deliberately blocked, so the declarative surface can't create/update/delete, but this is a stated constraint rather than an oversight.