Skip to main content
Glama
mondaycom

monday MCP Server

Official
by mondaycom

List Users and Teams

list_users_and_teams
Read-onlyIdempotent

Fetch users and teams from Monday.com using specific IDs or name search. Retrieve current user info, team details, or filter by user or team IDs.

Instructions

Tool to fetch users and/or teams data.

  MANDATORY BEST PRACTICES:
  1. ALWAYS use specific IDs or names when available
  2. If no ids available, use name search if possible (USERS ONLY)
  3. Use 'getMe: true' to get current user information
  4. AVOID broad queries (no parameters) - use only as last resort

  REQUIRED PARAMETER PRIORITY (use in this order):
  1. getMe - STANDALONE
  2. userIds
  3. name - STANDALONE (USERS ONLY, NOT for teams)
  4. teamIds + teamsOnly
  5. No parameters - LAST RESORT

  CRITICAL USAGE RULES:
  • userIds + teamIds requires explicit includeTeams: true flag
  • includeTeams: true fetches both users and teams, do not use this to fetch a specific user's teams rather fetch that user by id and you will get their team memberships.
  • name parameter is for USER search ONLY - it cannot be used to search for teams. Use teamIds to fetch specific teams.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userIdsNoSpecific user IDs to fetch.[IMPORTANT] ALWAYS use when you have user IDs in context. PREFER over general search. RETURNS: user profiles including team memberships
teamIdsNoSpecific team IDs to fetch.[IMPORTANT] ALWAYS use when you have team IDs in context, NEVER fetch all teams if specific IDs are available. RETURNS: Team details with owners and optional member data.
nameNoName-based USER search ONLY. STANDALONE parameter - cannot be combined with others. PREFERRED method for finding users when you know names. Performs fuzzy matching. CRITICAL: This parameter searches for USERS ONLY, NOT teams. To search for teams, use teamIds parameter instead.
getMeNo[TOP PRIORITY] Use ALWAYS when requesting current user information. Examples of when it should be used: ["get my user" or "get my teams"]. This parameter CONFLICTS with all others.
includeTeamsNo[AVOID] This fetches all teams in the account. To fetch a specific user's teams just fetch that user by id and you will get their team memberships.
teamsOnlyNoFetch only teams, no users returned. Combine with includeTeamMembers for member details.
includeTeamMembersNoSet to true only when you need additional member details for teams other than names and ids.
Behavior5/5

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

Annotations already indicate readOnlyHint and idempotentHint. The description adds valuable behavioral details: return types (user profiles with team memberships, team details with owners), warnings about broad queries, and that 'name' is for users only. It also explains the 'includeTeams' parameter's caveat.

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?

The description is well-structured with clear sections and bullet points, making it easy to scan. It front-loads the purpose. However, it is somewhat verbose; some repetition exists (e.g., 'name' restriction is restated). Still, the structure aids comprehension.

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?

Given the tool's complexity (7 parameters, no output schema), the description covers usage rules and return types for each parameter. It warns against broad queries and explains parameter interactions. A sample response or more explicit output structure would improve completeness, but it suffices.

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

Parameters5/5

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

Despite 100% schema coverage, the description significantly enhances parameter semantics. It explains return contents, standalone usage, and priority order. For example, it clarifies that 'name' is for user search only, and that 'includeTeams' should be avoided in favor of fetching a user by ID.

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?

The description clearly states the tool's purpose: 'Tool to fetch users and/or teams data.' The title 'List Users and Teams' is consistent. It distinguishes from sibling tools by focusing on user and team listing, which is unique among the many tools.

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?

The description provides excellent intra-tool usage guidelines with a prioritized parameter order (getMe, userIds, name, teamIds, no params) and detailed rules like 'userIds + teamIds requires includeTeams: true flag.' However, it does not compare this tool to alternatives like 'get_user_context' for current user info, missing some cross-tool guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mondaycom/mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server