Skip to main content
Glama
subbuyalla

WeTrack Enterprise MCP Server

by subbuyalla

wetrack_bulk_create_users

Bulk create user accounts in one go by supplying a list with first name, last name, email, and role. Set skip_invite_email for SSO-only users to avoid sending password invites.

Instructions

Bulk create multiple user accounts at once.

Args: users: List of user objects. Each must have: {first_name, last_name, email, role} — and optionally user_name. skip_invite_email: Set True for SSO-only users who won't use password login.

Example users list: [ {"first_name": "Alice", "last_name": "Wong", "email": "alice@co.com", "role": "VITHI_USER"}, {"first_name": "Bob", "last_name": "Jones", "email": "bob@co.com", "role": "EMPLOYEE"} ]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
usersYes
skip_invite_emailNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does add behavioral context by explaining that skip_invite_email is intended for SSO-only users and by listing required fields. However, it does not disclose important mutation behaviors: whether invite emails are sent by default, how duplicate emails are handled, whether creation is atomic or partially succeeds, or any permission requirements. For a bulk create operation, these gaps are noticeable but not disqualifying.

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?

The description is compact and well-organized: a one-line purpose statement, a clear Args section, and a concrete example. Every sentence contributes useful information and there is no redundant or filler content.

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?

The description covers the critical input structure and example, and an output schema exists so return values are presumably documented. However, for a bulk creation tool it omits important operational details that an agent might need: allowed role values are only exemplified, not enumerated, and there is no mention of duplicate handling, validation behavior, or partial failure semantics. These are meaningful gaps for a mutating bulk operation.

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?

The input schema provides only minimal structure (an array of objects with additionalProperties, and a boolean default). The description fully compensates by specifying exact required fields, the optional user_name, the meaning of skip_invite_email, and a complete example of the users list. This gives an agent everything needed to construct valid arguments.

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 opens with a specific verb+resource: 'Bulk create multiple user accounts at once.' This clearly distinguishes it from the sibling wetrack_create_user, which handles single-user creation. The required fields and example make the tool's purpose immediately understandable.

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 phrase 'Bulk create ... at once' implies this is for creating multiple users in one call, contrasting with the single-user sibling wetrack_create_user. The skip_invite_email guidance adds a concrete usage condition: set True for SSO-only users who won't use password login. It stops short of explicitly naming alternatives or when-not-to-use scenarios, but the context is clear.

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