Skip to main content
Glama
crunchtools

MCP WorkBoard CrunchTools

by crunchtools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Workboard List Users Tool

workboard_list_users_tool
Read-only

List WorkBoard users by team or organization, with paging via limit and offset; organization-wide listing requires a Data-Admin token.

Instructions

List WorkBoard users.

scope="team" (default) returns members of teams you can see and works for any account. scope="org" returns every user in the organization and requires a Data-Admin token. Returns up to 100 users; use limit and offset to page.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of users to return (default 100)
scopeNo"team" or "org" (org requires Data-Admin)team
offsetNoNumber of users to skip (optional)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.12.0
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 100,
+  "description": "Maximum number of users to return (default 100)",
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "anyOf": [
+    {
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Number of users to skip (optional)"
+}
    • addedInput schema / properties / scope
      Added value: +{
+  "default": "team",
+  "description": "\"team\" or \"org\" (org requires Data-Admin)",
+  "enum": [
+    "team",
+    "org"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changedv0.7.0
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare the read-only nature, and the description adds genuine behavioral context on top: the authorization requirement for org scope, the 100-user result cap, and the paging controls. It does not describe ordering, error behavior, or what happens when offset exceeds the result set.

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?

One-line purpose statement followed by two tight sentences covering scope semantics and pagination. Zero filler, and the most decision-relevant fact (default scope works for any account) is front-loaded.

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 an output schema present, return-value detail is unnecessary, and the description covers the pieces an agent must know before calling: scope, auth prerequisite, and paging. Only edge-case behavior (ordering, over-large offsets, token-missing failure mode) is left uncovered.

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 description coverage is 100%, so the baseline is 3. The description earns above baseline by explaining the functional consequence of scope (which users are visible, and why org needs a token) and by tying limit/offset together as a paging pair rather than restating the fields.

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 verb and resource ("List WorkBoard users") and immediately scopes it by team vs. org visibility, which separates it from mutation siblings like create_user/update_user. It does not, however, explicitly distinguish itself from overlapping read siblings such as workboard_get_team_members_tool or workboard_get_user_tool, leaving the choice to inference.

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?

Gives clear selection criteria between the two scope values and states the prerequisite for the broader one ("scope='org' ... requires a Data-Admin token"), plus the paging mechanism. There is no explicit when-not-to-use or named alternative among the sibling list, so it stops short of a full routing rule.

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

Deploy Server

Other Tools