Glasscubes MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GLASSCUBES_BASE_URL | No | Defaults to `https://api.glasscubes.com/rest`. Used by the tests. | https://api.glasscubes.com/rest |
| GLASSCUBES_CLIENT_ID | No | The client ID Glasscubes issued for your application. | |
| GLASSCUBES_ACCESS_TOKEN | No | A user's access token, sent as `Authorization: Bearer <token>` (a pasted `Bearer ` prefix is stripped). Required unless the three refresh variables are set. | |
| GLASSCUBES_ALLOW_WRITES | No | `true` to register `create_task` and `set_task_state`. Off by default. | false |
| GLASSCUBES_CLIENT_SECRET | No | The matching client secret. | |
| GLASSCUBES_REFRESH_TOKEN | No | That user's refresh token, for `POST /v2/auth/refresh`. Needs `GLASSCUBES_CLIENT_ID` and `GLASSCUBES_CLIENT_SECRET`. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_workspacesA | The current user's workspaces (a practice usually keeps one per client), with their group and whether they are pinned. Pages through the API 50 at a time until it returns a short page, which the API documents as the end of the list. q, group_id and label are passed through as the API's q, g and l parameters; the spec does not describe them further. |
| list_workspace_labelsA | Labels applied to the workspaces the current user can access, sorted alphabetically (as documented). A label containing an email, phone number, postcode or NI number is redacted unless include_contact_details is set; use the unredacted name for list_workspaces' label filter. |
| get_workspaceB | One workspace: name, the current user's permission (READ, COMMENTER, WRITE, OWNERSHIP), enabled modules, group and public page details. |
| list_workspace_membersA | Members of one workspace (users and user groups) with their names, company and active status. Email addresses only with include_contact_details. |
| list_information_requestsA | Information requests (document requests sent to clients) in one workspace: subject, status, due date, recipient name, and how many items are in each item status (WAITING presumably means the client has not provided the item yet; the API lists the statuses without saying what they mean). The statuses filter is applied by this server after fetching, because the API endpoint takes no filter. |
| get_information_requestA | One information request with every item (name, status, number of files provided, queries/responses/notes on it) and its assignments. Files are not downloaded. |
| list_request_templatesB | Information request templates with their item names: account-wide templates, or with workspace_id the templates within that workspace (as documented). |
| list_tasksA | Without workspace_id: the current user's My Tasks that are not completed (GET /v2/task/my). With workspace_id: the workspace's tasks; the API documents that it returns tasks that are not completed, with an order parameter of 'todo' (its default), 'all' or 'custom'. |
| get_taskB | One task with its state (NEW, STARTED, COMPLETED), dates, assignees, labels, attachment titles and form submissions. |
| list_filesA | Files and folders in a workspace's root, or in one folder with folder_id: titles, versions, sizes, who last updated them and labels. Metadata only; this server never downloads or previews a file. |
| list_calendar_eventsA | Calendar events in one workspace between two dates: title, times, attendees and their responses; the location (often an address) and attendee emails only with include_contact_details. Video-call links, host links and passwords are never returned. |
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 11 tools
Each tool targets a distinct resource+action, with clean get/list pairs (get_workspace vs list_workspaces, get_task vs list_tasks, get_information_request vs list_information_requests). The only mild overlap is between the singular information-request reader and the workspace-scoped list, but the descriptions distinguish them clearly enough.
Every tool follows the same snake_case verb_noun pattern (get_* / list_*) throughout. There are no mixed conventions or vague verbs.
11 tools is well within the ideal range and each one maps to a distinct resource or view. Nothing feels redundant or padded.
The read surface is broad, covering workspaces, members, labels, information requests, templates, tasks, files and calendar events. The main gap is the absence of any write/mutation operations (creating tasks, uploading files, commenting), though the server appears intentionally read-only, so agents can work within these bounds.