Skip to main content
Glama
pipeshub-ai

PipesHub MCP Server

Official
by pipeshub-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

pipeshub_directory

Read-onlyIdempotent

Look up people, groups, and teams in an organization. Use actions to identify yourself, list and search users, fetch user profiles, list groups, and view your teams.

Instructions

Look up people, groups, and teams in PipesHub. Five actions — pick action. Not for documents or files: that is pipeshub_search.

  • whoami — the caller's id, email, full name. Use before get_user on yourself. Errors if the credential is expired or revoked.

  • list_users — page org users; search matches name or email.

  • get_user — full User for one userId.

  • list_groups — org groups with userCount; search matches name.

  • list_my_teams — teams the caller is on, with canEdit / canDelete / canManageMembers; search matches name.

Omit page/limit for the first page (page 1). No match is an empty users/groups/teams array, not an error. pagination.hasNextPage (teams: hasNext) says whether to request the next page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page for list_* actions. Omit for page 1.
limitNoItems per page for list_* (1–100). Omit for the action default: 50 users, 25 groups, 100 teams.
actionYesWhat to do: - `whoami` — return the authenticated user's identity, confirmed against the server. No other args needed. - `list_users` — paginated list of org users. Optional `page`, `limit`, `search` (substring match against name or email). - `get_user` — full profile for one user. Required `userId`. Use `whoami` to find your own id first if needed. - `list_groups` — paginated list of user groups (with `userCount`). Optional `search` matches group name. - `list_my_teams` — teams the authenticated user belongs to, with capability flags. Optional `search` matches team name.
searchNoSubstring match on list_users (name or email), list_groups (name), and list_my_teams (name). An empty list means no match, not an error.
userIdNoRequired when `action` is `get_user`. 24-character ObjectId. Take it from `whoami` (yourself) or from a `list_users` hit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.4.2
    • changedInput schema / properties / action / description
      Previous value: -"What to do:\n- `whoami` — return the authenticated user's identity, confirmed against the server. No other args needed.\n- `list_users` — paginated list of org users. Optional `page`, `limit`, `search` (substring match against name or email).\n- `get_user` — full profile for one user. Required `userId`. Use `whoami` to find your own id first if needed.\n- `list_groups` — paginated list of user groups (with `userCount`).\n- `list_my_teams` — teams the authenticated user belongs to, with capability flags."New value: +"What to do:\n- `whoami` — return the authenticated user's identity, confirmed against the server. No other args needed.\n- `list_users` — paginated list of org users. Optional `page`, `limit`, `search` (substring match against name or email).\n- `get_user` — full profile for one user. Required `userId`. Use `whoami` to find your own id first if needed.\n- `list_groups` — paginated list of user groups (with `userCount`). Optional `search` matches group name.\n- `list_my_teams` — teams the authenticated user belongs to, with capability flags. Optional `search` matches team name."
    • changedInput schema / properties / limit / description
      Previous value: -"Pagination — items per page. Used by list_* actions."New value: +"Items per page for list_* (1–100). Omit for the action default: 50 users, 25 groups, 100 teams."
    • changedInput schema / properties / page / description
      Previous value: -"Pagination — 1-based page number. Used by list_* actions."New value: +"1-based page for list_* actions. Omit for page 1."
    • changedInput schema / properties / search / description
      Previous value: -"Substring match against name / email. Used by list_users."New value: +"Substring match on list_users (name or email), list_groups (name), and list_my_teams (name). An empty list means no match, not an error."
    • changedInput schema / properties / userId / description
      Previous value: -"Required when `action` is `get_user`. 24-character ObjectId."New value: +"Required when `action` is `get_user`. 24-character ObjectId. Take it from `whoami` (yourself) or from a `list_users` hit."
  2. First observedv2.3.3

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, but the description adds significant behavioral context: error on expired/revoked credential for whoami, empty arrays for no matches, pagination via hasNextPage/hasNext, and page/limit defaults. No contradictions; the description enriches beyond annotations.

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?

Well-structured with a clear opening, bulleted action list, and concise pagination/error notes. Every sentence adds value; no fluff. Front-loaded with the primary purpose and sibling differentiation, making it easy to scan.

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?

Covers all actions, parameters, error conditions, pagination, and alternatives. Even without an output schema, it describes return arrays (users/groups/teams) and capability flags. Nothing an agent needs to call it correctly 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 covers all parameters at 100%, so baseline is 3. The description adds cross-parameter dependencies (userId required for get_user, search only applies to list_* actions), clarifies action-specific requirements, and explains pagination behavior. This goes beyond schema, but the schema already provides solid descriptions, so a 4 is appropriate.

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?

States a specific verb and resource: 'Look up people, groups, and teams in PipesHub.' Lists five distinct actions and explicitly differentiates from pipeshub_search for documents/files. An agent can immediately understand scope and distinguish from siblings.

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

Usage Guidelines5/5

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

Explicitly says 'Not for documents or files: that is pipeshub_search,' naming the alternative and when not to use this tool. Also provides per-action guidance, e.g., 'Use before get_user on yourself' and explains pagination defaults and error behavior. Clear when-to-use and when-not-to-use context.

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