How do I use Glasscubes MCP server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Glasscubes MCP server Which clients still owe us year-end documents, and what's missing?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Glasscubes MCP server

by dragosh29

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Glasscubes MCP server

An MCP server that lets Claude, ChatGPT and other MCP clients work with a Glasscubes client portal: workspaces, information requests (document requests sent to clients, and which items are still outstanding), tasks, file and folder metadata, workspace members and calendar events, and (when enabled) creating tasks and changing their state. It is built from Glasscubes' public API documentation and its published Swagger 2.0 document (https://api.glasscubes.com/rest/swagger.json).

Once it's connected, someone at the practice can ask things like:

"Which clients still owe us year-end documents, and which items are missing?"
"What's overdue in the Evans Bakery workspace?"
"What are my open tasks, and what's on the Evans calendar in October?"
"What's in the Year end 2026 folder, and who uploaded the last bank statement?"
With writes enabled: "Create a task for Jo to chase Priya for her P60 by 20 October, and mark 'Draft Evans accounts' as completed."

Tools

Tool	What it does	API calls
`list_workspaces`	The current user's workspaces with group and pinned flag. Pages 50 at a time until a page comes back shorter than asked for, which the API documents as the end. `query`, `group_id` and `label` are passed through as the API's `q`, `g` and `l` parameters (the spec does not describe them).	`GET /v3/workspace-list/{first}/{count}`
`list_workspace_labels`	Labels on the workspaces the user can access.	`GET /v3/workspace-list/labels`
`get_workspace`	One workspace: the user's permission, modules, group, public page.	`GET /v2/workspace/{id}`
`list_workspace_members`	Members (users and user groups) with names, company and active status.	`GET /v2/workspace/{id}/members`
`list_information_requests`	Requests in a workspace with status, due date, recipient name and a count of items per item status. Optional `statuses` filter, applied by this server because the endpoint takes none.	`GET /v2/irequest/workspace/{id}`
`get_information_request`	One request with every item's status, file count and query/response/note counts, and its assignments.	`GET /v2/irequest/{id}`
`list_request_templates`	Account-wide templates, or a workspace's with `workspace_id`.	`GET /v2/irequest/templates`
`list_tasks`	The user's My Tasks, or a workspace's tasks with the documented `order` parameter (`todo`, `all`, `custom`).	`GET /v2/task/my`, `GET /v2/task/workspace/{id}`
`get_task`	One task with state, dates, assignees, labels, attachment titles and form submissions.	`GET /v2/task/{id}`
`list_files`	Files and folders in a workspace root or one folder: titles, versions, sizes, who updated them, labels. Metadata only.	`GET /v2/file/browse/{wid}`, `GET /v2/file/browse/{wid}/{fid}`
`list_calendar_events`	Events in a workspace between two dates (sent in the documented `dd-MM-yyyy` form): titles, times, attendees and responses; the location only on request.	`GET /v2/cal/get-events/{workspaceId}/{startDate}/{endDate}`
`create_task`	Creates a task in a workspace or in the user's My Tasks, with optional due date and user/group assignees. Title up to 253 and description up to 63,999 characters: this server's own limits, borrowed from the post endpoint (the spec documents none for tasks). Only registered when writes are enabled.	`PUT /v2/task`
`set_task_state`	Reads the task, sets it to `NEW`, `STARTED` or `COMPLETED`, then reads it back; returns `previous_state` so the change can be undone. Only registered when writes are enabled.	`GET /v2/task/{id}`, `POST /v2/task/{id}/state`, `GET /v2/task/{id}`

Not covered on purpose: file downloads, previews and signed URLs (never called); sending, deleting or editing information requests; e-signatures, forms, posts, polls, portfolios, workspace creation and membership changes; the "(Internal)" operations in the spec; and GET operations that change state, which the spec contains and this server never calls: GET /v2/cal/delete-event/{eventId} (deletes an event), GET /v2/file2/{id}/lock/add and /lock/remove, GET /v2/user/expiretoken and GET /v2/user/invalidate (end the current token). There is no reminder endpoint for information requests in the spec, so there is no reminder tool.

Related MCP server: jurisly-mcp

Setup

Requires Node 18 or later.

npm install
npm run build

Credentials

Glasscubes issues a client_id and client_secret to an application on request ("Simply contact us for your client ID", support article "Glasscubes API"). With those, the API documentation describes getting a user's access token from /auth/{cid}/passwd with that user's email address and password; /auth/code (a code handed to your redirect URL after the user logs in) is listed in the spec but the documentation page says it "is not currently supported, however it can be implemented on request". Access tokens are valid for 24 hours; /auth/refresh exchanges a refresh token for a new access and refresh token pair.

This server never takes an email address or password and never calls the password endpoint. It takes tokens you already have:

GLASSCUBES_ACCESS_TOKEN on its own works for up to 24 hours.
Add GLASSCUBES_REFRESH_TOKEN with GLASSCUBES_CLIENT_ID and GLASSCUBES_CLIENT_SECRET and the server renews the access token itself through POST /v2/auth/refresh when the API rejects it. With these three set, the access token can be left out and the server refreshes before its first call.

Claude Desktop: add this to claude_desktop_config.json:

{
  "mcpServers": {
    "glasscubes": {
      "command": "node",
      "args": ["/absolute/path/to/glasscubes-mcp/dist/index.js"],
      "env": {
        "GLASSCUBES_ACCESS_TOKEN": "your-access-token",
        "GLASSCUBES_REFRESH_TOKEN": "your-refresh-token",
        "GLASSCUBES_CLIENT_ID": "your-client-id",
        "GLASSCUBES_CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

Claude Code:

claude mcp add glasscubes \
  -e GLASSCUBES_ACCESS_TOKEN=your-access-token \
  -e GLASSCUBES_REFRESH_TOKEN=your-refresh-token \
  -e GLASSCUBES_CLIENT_ID=your-client-id \
  -e GLASSCUBES_CLIENT_SECRET=your-client-secret \
  -- node /absolute/path/to/glasscubes-mcp/dist/index.js

Variable	Required	Meaning
`GLASSCUBES_ACCESS_TOKEN`	yes, unless the three refresh variables are set	A user's access token, sent as `Authorization: Bearer <token>` (a pasted `Bearer` prefix is stripped).
`GLASSCUBES_REFRESH_TOKEN`	no	That user's refresh token, for `POST /v2/auth/refresh`. Needs the two variables below.
`GLASSCUBES_CLIENT_ID`	with a refresh token	The client ID Glasscubes issued for your application.
`GLASSCUBES_CLIENT_SECRET`	with a refresh token	The matching client secret.
`GLASSCUBES_ALLOW_WRITES`	no	`true` to register `create_task` and `set_task_state`. Off by default.
`GLASSCUBES_BASE_URL`	no	Defaults to `https://api.glasscubes.com/rest`. Used by the tests.

Safety defaults

Read-only unless GLASSCUBES_ALLOW_WRITES=true. Read tools carry the MCP readOnlyHint annotation. create_task only adds, so it is marked not destructive and not idempotent. set_task_state overwrites a task's state, so it is marked destructive (and idempotent); it reads the task first and returns previous_state, which can be passed back to undo the change.
Personal data of clients and staff: names, company names and client codes are returned; email addresses (members, task assignees, request recipients and assignments, calendar attendees), calendar event locations (often an address), an information request's publicUrl and each assignment's publicUrl (links into the client's view of the request) are only returned with include_contact_details=true. Profile picture URLs are never returned.
Free text is redacted unless include_contact_details=true: names of people, workspaces, workspace groups, user groups, modules and labels, client codes, request subjects, descriptions and item names, task titles and descriptions, file and folder titles, form names, event titles and descriptions, a public workspace's title and description, template names, and Glasscubes' own error messages. In all of these, email addresses become [email redacted], phone-number-like sequences [phone redacted], UK postcodes (any case) [postcode redacted] and National Insurance numbers [NI number redacted]. A payment card number (13 to 19 digits that pass the Luhn check) becomes [card number redacted] whether or not contact details were requested. The phone match is a heuristic: international numbers written with + or 00 (optionally with a bracketed trunk prefix or area code, as in +44 (0)7700 900123 or +1 (415) 555-2671), UK numbers with a bracketed area code, and UK-style 0… numbers of 9 to 11 digits; other digit strings starting with 0 are redacted too.
Not redacted, because they cannot be told apart from ordinary text, dates, references and figures: street addresses (only the postcode is caught), dates of birth, UTRs, bank sort codes and account numbers, and money amounts such as salaries. A practice that types these into request descriptions, task text or file titles will see them returned.
Calendar events never include video-call details: Zoom host and join links and passwords, Teams join links and conference codes are dropped; has_video_call says whether there is one.
No file is ever downloaded or previewed; list_files returns metadata only.
IDs must be positive whole numbers of at most 15 digits (the spec types every path ID as integer/int64; 15 digits keeps every ID exact as a JSON number, which is how create_task sends workspace and assignee IDs); anything else is refused before a request is made. Calendar dates must be real YYYY-MM-DD dates with from not after to; create_task refuses a start date after the due date (the API's errCode 130) and a start date without a due date, before sending anything.
Errors follow the documented convention (HTTP 400 with {errCode, errMsg}). errCode 121 or 115, or an HTTP 401, is treated as a rejected token: with refresh configured the token is refreshed once and the request repeated, otherwise the message says to check GLASSCUBES_ACCESS_TOKEN. errCode 120, 133 or 200 (or an HTTP 404) is reported as not found; 116 as access denied; 100, 109 to 113 and 119 as a problem with the account or user. The access token, refresh tokens and client secret are replaced with [redacted] if they ever appear in an error message.
Glasscubes documents no rate limit and no 429. Requests are spaced 250 ms apart. A 429 is retried at most twice for any method, waiting for Retry-After (seconds, fractional seconds or an HTTP-date; 2 s then 4 s when absent); a wait longer than 10 seconds makes the call give up at once and say how long to wait. 502, 503 and 504 are retried the same way for GET only (the suite exercises 502 on a GET; 503 and 504 take the same code path). PUT /v2/task and POST /v2/task/{id}/state are never retried after a gateway error, because the request may already have been processed; the message says to check with list_tasks or get_task first. The token refresh (a POST) is not retried after a gateway error either.
A read that gets a 200 whose body is not JSON (a proxy or login page), is empty, or is JSON of the wrong shape (null or an object where the API documents a list; null, a list or an empty object where it documents a single record) is an error saying the result is unknown, never an empty list: "no documents outstanding" must not come from a missing answer. An empty 200 body is accepted only from the writes: POST /v2/task/{id}/state documents no response body, and a PUT /v2/task that answered 200 without the created task is reported as created with a note to check list_tasks.

Tests

npm test

The suite runs offline once spec.json is present (it is gitignored and downloaded from https://api.glasscubes.com/rest/swagger.json on the first run if missing). It takes about 45 seconds.

Validates every fixture record against the Swagger 2.0 definitions (WorkspaceListItem, WorkspaceListLabel, WorkspaceInfoV3, WorkspaceMemberInfo, InformationRequestReadDto, InformationRequestTemplateReadDto, TaskResponse, DiscItem, EventInfo) with Ajv in draft-04 mode, and also fails on any key a definition does not declare, since the definitions allow extra keys and mark almost nothing required. Two negative controls prove the schema and the key walk actually reject things.
Starts a local mock of the API under /rest that serves those fixtures and validates its list, detail and task-creation responses against each operation's documented response schema. The spec publishes no schema for errors; the mock's error bodies follow the documentation page's {errCode, errMsg} form and are validated against a schema written from that text. The mock answers a missing or wrong token with 400 and errCode 121, an unknown ID with 400 and errCode 120 "Item deleted", a bad calendar date with errCode 144, and a wrong refresh token with errCode 104 (all documented codes; which one the live API sends in each case is the mock's assumption). The refresh operation's documented form fields and content type are asserted from the spec.
Starts the built server and drives it over stdio with the official MCP client: 28 checks covering tool names and annotations (and that no task length limit is attributed to the API), every read tool, first/count paging to the documented short page with requests about 250 ms apart (and continuing from first), a page of count+1 cut to max_results, max_results caps on information requests and tasks, q/g/l, workspaceId and order passed through, the local statuses filter, the redaction patterns themselves (including what they do not catch), redaction of emails, phones, postcodes and NI numbers by default in free text and in workspace, group, module and label names and client codes, and their return on request, event locations only on request, card numbers redacted always, profile pictures and video-call secrets never returned, no download endpoint ever called, the PUT /v2/task body validated against the spec's TaskRequest (15-digit IDs sent exactly), a PUT answered 200 without a body, the state change as a query parameter with previous_state read first and used to undo, local refusals, bad IDs (including 16 digits and more), statuses, order and bounds refused before any request, the not-found (errCode 120, 133, 200 and HTTP 404), access-denied (116) and account-error (100, 109 to 113, 119) messages, an expired token refreshed with the documented form POST and the rotated refresh token used next time, starting with only a refresh token, a refresh that hits a 502 not retried, an early refresh before the expiresIn a refresh returned, three simultaneous calls sharing one refresh, and a token rejected again after refreshing reported without a second refresh, error text redacted with the access token, refresh token and client secret scrubbed, the 429 retry (seconds, fractional and HTTP-date Retry-After, the 2 s fallback when it is missing, a persistent 429, a wait above the cap, a 429 on PUT /v2/task retried once), 502 retried for GET (and reported after 3 in a row), a 502 on the PUT and a 503 on the POST never retried, a 200 that is not JSON, empty, or JSON of the wrong shape for every read tool, the write gate (unset and false), wrong access and refresh tokens (errCode 121 and 115, and an undocumented 401), a pasted Bearer prefix, and, as the last check, that every request of the whole run went under /rest, carried a Bearer token the mock issued or the deliberately wrong one of the wrong-token checks (none on the refresh), and matched a documented method and path, and that the password route was never called.

Status

This is a working prototype. It has not been run against the live API, because it was built without a Glasscubes account (there is no free trial and client IDs are issued on request). Everything below comes from the spec and the documentation page and should be confirmed on a real account:

What an expired or wrong token gets back. The documentation lists general errors 121 ("OAuth problem…") and 115 ("Unauthorised access") without saying which one, and with which HTTP status, a bad token produces; the server refreshes on either (and on a 401).
What an unknown ID gets back. The mock answers 400 with errCode 120 "Item deleted", which the spec documents for a missing workspace on several endpoints; the live API might instead answer 200 with an empty body or null, which this server reports as an unknown result rather than as not found.
Token refresh: whether POST /v2/auth/refresh really rotates the refresh token (the documentation says it returns "a new user access token and refresh token pair") and whether the old one stops working. The new pair is kept in memory only, so after a restart the refresh token in the environment may already have been used; the error message then says to obtain a new pair.
What q, g and l on GET /v3/workspace-list/{first}/{count} do (the spec gives no description; the mock reads them as a name search, a group ID and a label), and the largest count the API accepts (50 per page is this server's own choice).
Whether that page covers [first, first+count) or, as the summary writes it, [first, first+count]. The mock serves the half-open range (at most count items); the server advances by the number of items actually returned and cuts the result to max_results, so either reading works, and the tests include a page of count+1.
order on GET /v2/task/workspace/{id}: the spec says the endpoint returns tasks that are not completed, and lists todo, all and custom without saying whether all includes completed tasks. The mock ignores it.
Task dates. The spec asks for the beginning and end of the day, then converted to UTC; this server takes the day boundaries in UTC and sends T00:00:00.000Z and T23:59:59.000Z on the given days, so during British Summer Time the task spans 01:00 to 00:59 UK time. Whether startDate may be omitted when endDate is given is not documented; the server always sends both.
The response of POST /v2/task/{id}/state, documented only as "default: successful operation" with no body.
Length limits for task titles and descriptions: the spec documents none for tasks. create_task refuses titles over 253 and descriptions over 63,999 characters on its own, borrowing the limit the spec documents for PUT /v2/post (errCode 125).
The meaning of the item statuses (WAITING, COMPLETE, DELEGETED, AMEND, RESUBMITED, VERIFIED, DECLINED) and request statuses; the spec lists them without descriptions, so the server reports counts per status rather than deciding which are "outstanding". The tool descriptions say WAITING presumably means not yet provided, and say that this is an assumption.
For STANDARD versus PERSONAL_TAX requests, which of sentToUser, sentToEmail, firstName/lastName and clientCode are filled in.
Whether the calendar range is inclusive and in which time zone the dates are read.
Rate limits: none documented, and no 429 appears in the spec; the throttle is a guess on the polite side.
Whether Glasscubes' errMsg texts ever echo personal data or tokens; the server redacts and scrubs them regardless.

Going to production

This version runs locally over stdio with one user's tokens. For a practice to connect from claude.ai or ChatGPT without handling tokens, the next step is a remote server (Streamable HTTP) behind OAuth, hosted by Glasscubes, built on the /auth/code flow the documentation says can be enabled, and then a listing in the Claude and ChatGPT connector directories.

Licence

MIT. Built by Alexandru Dragoș (alexandru.dragos96@gmail.com) with an AI agent (Claude) working under his direction.

Available Tools

11 tools

get_information_requestGet information requestA

Read-only

One information request with every item (name, status, number of files provided, queries/responses/notes on it) and its assignments. Files are not downloaded.

ParametersJSON Schema

Name	Required	Description	Default
`request_id`	Yes	Information request ID
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral caveat beyond that: 'Files are not downloaded,' telling the agent that only file metadata/counts are returned, not file content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences: the first front-loads the purpose and return payload, the second delivers the file caveat. No filler, though the parenthetical field list is slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries return-value disclosure and does it well by enumerating items, their fields, and assignments. Combined with annotations covering the safety profile and a 100%-documented schema, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both request_id and include_contact_details (including its redaction implications) are fully documented in the schema. The description adds no parameter-level detail, which is the expected baseline when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource ('One information request') and enumerates what comes back (items with name, status, file counts, queries/responses/notes, plus assignments). The singular 'One' implicitly contrasts with the sibling list_information_requests, though the sibling is never named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: fetching a single request by ID. There is no explicit statement of when to prefer this over list_information_requests or get_task, and no prerequisites or exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_taskGet taskB

Read-only

One task with its state (NEW, STARTED, COMPLETED), dates, assignees, labels, attachment titles and form submissions.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes	Task ID
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value by enumerating the returned payload, but it never discloses that fields are redacted by default or that include_contact_details unlocks PII — a meaningful behavioral trait left entirely to the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with no wasted words, front-loading the resource and the returned fields. It is a noun fragment with no verb, which slightly weakens the opening but keeps it efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does useful work by enumerating the returned data categories. Combined with full schema coverage and read-only annotations, an agent has enough to call it correctly; only error/permission behavior and default-redaction implications are unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (including the redaction semantics of include_contact_details) are already fully documented in the schema. The description adds no syntax, format, or constraint detail beyond what the schema provides, making the baseline of 3 correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and enumerates exactly what is returned ('One task with its state (NEW, STARTED, COMPLETED), dates, assignees, labels, attachment titles and form submissions'). The singular 'One task' implicitly distinguishes it from the sibling list_tasks, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no statement that a task_id is required to invoke it, and no routing to alternatives such as list_tasks for multiple records. Usage must be inferred purely from the name and the singular noun phrase.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_workspaceGet workspaceB

Read-only

One workspace: name, the current user's permission (READ, COMMENTER, WRITE, OWNERSHIP), enabled modules, group and public page details.

ParametersJSON Schema

Name	Required	Description	Default
`workspace_id`	Yes	Workspace ID
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the shape of what is returned (permission level, enabled modules, group/public page details), which goes slightly beyond the annotations, but says nothing about auth requirements or the privacy consequences of include_contact_details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence fragment with no waste; the resource is stated first and the returned fields follow. It is terse to the point of reading like a field list rather than guidance, but nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with no output schema, the enumeration of returned fields (name, permission, modules, group/public page details) gives the agent a useful sense of the payload. Combined with annotations covering safety, little essential information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both workspace_id and include_contact_details (including its redaction implications) are fully documented in the schema. The description adds no parameter-level meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and its scope ('One workspace'), which implicitly contrasts with the sibling list_workspaces. It clearly implies retrieval of a single workspace entity, though no explicit verb or explicit sibling routing statement is given.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus list_workspaces or the other workspace-scoped siblings like list_workspace_members or list_workspace_labels. The agent must infer that a single workspace is fetched by ID, with no stated prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_calendar_eventsList calendar eventsA

Read-only

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.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Last day, YYYY-MM-DD
`from`	Yes	First day, YYYY-MM-DD
`workspace_id`	Yes	Workspace ID
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/openWorld/non-destructive, yet the description adds real behavioral context: location and attendee emails appear only when include_contact_details is set, and video-call links, host links and passwords are never returned. That is meaningful disclosure of redaction policy beyond the annotations, though nothing is said about pagination, limits or ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads scope and returned data, then the caveats. Every clause carries information, though the grammar is slightly broken around 'the location (often an address) and attendee emails only with include_contact_details', which costs a little readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly carries the burden of describing return content (title, times, attendees and their responses, plus the conditional contact fields) and the never-returned fields. It is essentially complete for a 4-parameter read tool; only ordering/pagination detail is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description goes further by explaining the consequence of include_contact_details (contact fields appear/redaction lifts) and by framing from/to as a between-two-dates window. It adds semantic value the schema's terse field notes only partially convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource (calendar events) and scopes it precisely to one workspace and a date window, then enumerates the main returned fields (title, times, attendees and responses). No sibling tool covers calendars, so no differentiation is required; the only deduction is that the sentence is a noun fragment rather than a stated verb+resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The date-range and workspace scoping imply when the tool applies, but there is no explicit when-to-use or when-not-to-use statement and no named alternative. For a read-only listing tool with no competing calendar sibling this is adequate but thin.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_filesList files and foldersA

Read-only

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.

ParametersJSON Schema

Name	Required	Description
`folder_id`	No	Folder ID (from a previous list_files); omit for the workspace root
`workspace_id`	Yes	Workspace ID
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly=true, destructive=false, openWorld=true, so the safety profile is known. The description adds real behavioural context beyond them: it is metadata-only and never downloads or previews content, which prevents an agent from assuming it can retrieve file bodies. No pagination or result-limit behaviour is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the scoping rule front-loaded and the never-downloads caveat closing it. The colon-separated field list in the middle is dense but earns its place by summarising the return payload.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description correctly carries the return-value burden by enumerating the fields surfaced. Combined with annotations covering the read-only profile, the main remaining gap is pagination/ordering, which is not addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents workspace_id, folder_id and include_contact_details fully. The description reinforces the folder_id root-vs-folder semantics, which is the one parameter behaviour worth restating, but adds no syntax or format detail beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names the resource (files and folders), the exact scope (a workspace's root, or one folder when folder_id is supplied), and the fields returned (titles, versions, sizes, last updater, labels). An agent can distinguish this from list_workspaces or list_tasks without inspecting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the branch condition for folder_id ('or in one folder with folder_id') and implicitly excludes fetching content via 'this server never downloads or previews a file.' No sibling alternatives are named, but the scope is clear enough to know when to reach for it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_information_requestsList information requestsA

Read-only

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.

ParametersJSON Schema

Name	Required	Description
`statuses`	No	Only requests with one of these statuses (filtered locally)
`max_results`	No
`workspace_id`	Yes	Workspace ID
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/openWorld/non-destructive, and the description adds real context beyond them: that the statuses filter is executed server-side after fetching because the upstream API takes no filter, and a candid caveat that the API does not document what statuses mean. It stops short of covering pagination or result-size behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource, and the local-filter caveat earns its place. It is a dense, slightly run-on construction, with the parenthetical speculation about WAITING being a mild digression, but there is little waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by listing the returned fields, and annotations cover the safety profile for this read-only tool. The main gap is the absence of any when-to-use routing, but otherwise an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so the schema largely documents statuses, workspace_id, and include_contact_details itself. The description reinforces the local-filtering semantics of statuses and flags the opacity of status values, but adds nothing for max_results and no format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (information requests, glossed as 'document requests sent to clients') scoped to one workspace, and even enumerates returned fields (subject, status, due date, recipient, item-status counts). The plural/list nature distinguishes it implicitly from get_information_request, but no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to choose this tool over get_information_request or any other sibling, and no prerequisites or exclusions are given. The only adjacent guidance is a behavioral note that the statuses filter is applied locally, which is not usage routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_request_templatesList information request templatesB

Read-only

Information request templates with their item names: account-wide templates, or with workspace_id the templates within that workspace (as documented).

ParametersJSON Schema

Name	Required	Description	Default
`workspace_id`	No	Passed as the API's workspaceId query parameter

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that results are scoped account-wide or by workspace, but the trailing '(as documented)' is an unhelpful pointer rather than concrete behavioral detail (e.g., pagination, ordering).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single sentence, so not bloated, but the structure is awkward and the trailing '(as documented)' is filler that does not earn its place. The scoping condition would be clearer front-loaded as two distinct cases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with no output schema and a single optional parameter, the description conveys the result content and scoping. It omits ordering/pagination and any note on what 'item names' includes, leaving small but real gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the schema only says workspace_id maps to the API's workspaceId query parameter. The description adds the real semantic: passing it narrows results to templates within that workspace, versus account-wide templates when omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the resource (information request templates) and what is returned (their item names), which separates it from get_information_request and list_information_requests. It is clear but does not explicitly differentiate itself from the other list_* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It hints at the two usage modes (omit workspace_id for account-wide, pass it for workspace-scoped), which implies when to use each form. However, it gives no explicit guidance on when to choose this tool over list_information_requests or other siblings, so usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tasksList tasksA

Read-only

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'.

ParametersJSON Schema

Name	Required	Description
`order`	No	Passed as the API's order parameter; only with workspace_id
`max_results`	No
`workspace_id`	No	Workspace ID; omit for the current user's own tasks
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower; the description still adds meaningful behavior by disclosing that the API defaults to returning only not-completed tasks and that 'todo' is the default order. It hedges with 'the API documents that', and does not mention pagination or rate limits, so it is not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences covering both branches of behavior, with the no-workspace case front-loaded. It is efficient, though the nested parenthetical about the API's documentation adds a bit of clutter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with no output schema and four parameters, the description covers the branch logic and the default incomplete-task filter, which is the most important behavior. However, it omits result-size/pagination behavior (max_results defaults to 200, caps at 1000) and any note that include_contact_details alters redaction, leaving gaps an agent must infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so most parameters are already documented structurally. The description adds that order accepts todo/all/custom and is its default, and reinforces the workspace_id conditional, but says nothing about max_results or the privacy implications of include_contact_details beyond what the schema already states. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource and, unusually, splits the scope by parameter: without workspace_id it lists the current user's incomplete 'My Tasks', with workspace_id it lists the workspace's tasks. This is a clear, precise statement of what the tool returns. It does not explicitly distinguish itself from siblings like get_task or list_information_requests, but the name plus scope text make the boundary reasonably obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear conditional guidance: pass workspace_id or omit it, and the order parameter only applies with workspace_id. Uses a clear context but names no alternatives or when-not-to-use conditions, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_workspace_labelsList workspace labelsA

Read-only

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.

ParametersJSON Schema

Name	Required	Description	Default
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), yet the description adds meaningful behavior: the fields subject to masking (email, phone, postcode, NI number) and the toggle that disables it. Sorting is a minor addition. Pagination/return format is not addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with what is listed and the redaction caveat. The parenthetical '(as documented)' is slightly redundant filler, but overall the text is tight and well-ordered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only, single-optional-parameter list tool with full annotation coverage and no output schema, the description supplies everything needed: scope, ordering, redaction behavior and the param's downstream use. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents include_contact_details, making 3 the baseline. The description goes further by tying the parameter's effect to downstream use (the unredacted name for list_workspaces' label filter), adding meaning beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (labels) and scopes it precisely to workspaces the current user can access, plus states ordering. It is clear what the tool returns, though it does not explicitly contrast its purpose against sibling list tools like list_workspaces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operational context: redaction applies unless include_contact_details is set, and the result's unredacted name should feed list_workspaces' label filter. It lacks an explicit 'use this instead of X when Y' framing, but the workflow guidance is concrete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_workspace_membersList workspace membersA

Read-only

Members of one workspace (users and user groups) with their names, company and active status. Email addresses only with include_contact_details.

ParametersJSON Schema

Name	Required	Description	Default
`workspace_id`	Yes	Workspace ID
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond them by disclosing the fields returned and the conditional exposure of email addresses, effectively warning that contact data is withheld by default. It stops short of describing pagination or result-size behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with what is returned and the workspace scoping, then the conditional email caveat. Every clause carries information; nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates the returned member fields and clarifies that a workspace_id is required implicitly. It lacks pagination/ordering or permission notes, but for a simple read-only listing with full schema coverage it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents both parameters, including the detailed redaction behavior of include_contact_details. The description only restates the email-address aspect of that flag without adding syntax, defaults, or scope beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (members - both users and user groups) scoped to 'one workspace', plus the fields returned (names, company, active status). It is clear what the tool retrieves, though it does not explicitly contrast itself with siblings like get_workspace or list_workspaces (the sibling set is mostly different resources, so ambiguity is low).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the resource ('list members of a workspace'), and the description hints that email addresses only appear when include_contact_details is set, which is a conditional usage cue. There is no explicit when-to-use vs. alternative statement and no stated prerequisites (e.g. permissions needed to see contact details).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_workspacesList workspacesA

Read-only

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.

ParametersJSON Schema

Name	Required	Description
`first`	No	Index of the first workspace (0-based), for continuing a previous call
`label`	No	Passed as the API's l parameter (undocumented; presumably a workspace label from list_workspace_labels)
`query`	No	Passed as the API's q parameter (undocumented; presumably a name search)
`group_id`	No	Passed as the API's g parameter (undocumented; presumably a workspace group ID)
`max_results`	No
`include_contact_details`	No	Include email addresses, event locations and the links into a client's view of a request, and stop redacting emails, phone numbers, postcodes and NI numbers from names, labels and other free text

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the 50-per-page pagination loop and its 'short page means end of list' termination rule, plus the privacy consequence of include_contact_details (redaction disabled).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the scope and return shape front-loaded, followed by pagination behavior and the parameter passthrough caveat. Dense but every clause carries information; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still conveys the return shape at a high level (workspaces with group and pinned flag) and the pagination contract. The one gap is that first and max_results semantics are left entirely to the schema, but the essential calling contract is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already documents most parameters. The description's note that q, group_id and label map to the API's q, g and l parameters and that the upstream spec does not document them largely restates what the schema fields already say, adding only mild extra confidence about their opacity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('The current user's workspaces') and adds scope ('a practice usually keeps one per client') plus the fields surfaced (group, pinned status). It does not, however, name the sibling it competes with (get_workspace, list_workspace_members), so an agent must infer the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance and no alternatives are named, despite siblings like get_workspace and list_workspace_members that overlap. The only contextual hint is that a practice keeps one workspace per client, which describes the data rather than when to call this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesv0.1.0Oct 7, 2026
- First observedget_information_request
- First observedget_task
- First observedget_workspace
- First observedlist_calendar_events
- First observedlist_files
- First observedlist_information_requests
- First observedlist_request_templates
- First observedlist_tasks
- First observedlist_workspace_labels
- First observedlist_workspace_members
- First observedlist_workspaces

Deploy Server

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

A3.8/5.0

Scored 2026-10-07 18:25 across 11 tools

Disambiguation4/5

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.

Naming Consistency5/5

Every tool follows the same snake_case verb_noun pattern (get_* / list_*) throughout. There are no mixed conventions or vague verbs.

Tool Count5/5

11 tools is well within the ideal range and each one maps to a distinct resource or view. Nothing feels redundant or padded.

Completeness4/5

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.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Conector Juspronto A
br.com.juspronto
JusPronto is case-management software for Brazilian law firms. Its remote MCP server (OAuth 2.1 with PKCE, per-permission scopes, audit log) lets Claude and ChatGPT read the firm's own cases, deadlines, agenda, recent court movements and case files with the page cited. Write actions require the lawyer's approval. Requires a JusPronto account.
Legal & Compliance
231
AhsuiteOAuth
com.ahsuite
Build and run client portals for your agency: pages, tasks, forms, file requests and messages.
Project Management Communication Content Management Systems
1
Vertical FlowsOAuth
com.verticalflows
View client requests, prepare actions and approve work within your firm's permissions.
Customer Support Project Management App Automation
1
BriefGateOAuth
io.github.sekera-radim
Client intake: files, copy and logins from clients, from the browser or your AI agent.
App Automation Cloud Storage Security
1

Related MCP Servers

clio-mcp
Legal & Compliance CRM Project Management
oktopeak
A
license
Not graded
quality
A
maintenance
Connects Claude to Clio practice management, enabling AI-assisted access to matters, contacts, documents, tasks, and billing with audit logging and encryption for law firm compliance.
Updated 4 days ago (2026-10-19 14:08 UTC)
138 npm
25
MIT
jurisly-mcp
Legal & Compliance Project Management
omnimorphpvtltd
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Jurisly workspaces for tasks like drafting invoices, finding hearing dates, and editing documents through natural language.
Updated 3 months ago (2026-07-28 19:04 UTC)
Apache 2.0
AdvBox
Legal & Compliance CRM Finance
mcp-dir
A
license
Not graded
quality
C
maintenance
Enables AI assistants to read, create, and update legal practice data—cases with history and movements, clients, tasks, and financial transactions—using the firm's API token.
Updated 2 months ago (2026-08-30 19:42 UTC)
MIT
Projuris ADV
Legal & Compliance CRM
mcp-dir
A
license
Not graded
quality
C
maintenance
Enables AI assistants to read, search, and create/edit legal practice management data in Projuris ADV, including cases, people, tasks, updates, timesheet, files, contracts, subjects, court notices, service records, finance, and users via REST.
Updated 2 months ago (2026-08-30 19:47 UTC)
1
MIT