Skip to main content
Glama
JLKmach

ServiceNow MCP Server

by JLKmach

create_user

Add new user accounts to ServiceNow by providing essential details like username, name, email, and optional information such as department, roles, and contact numbers.

Instructions

Create a new user in ServiceNow

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_nameYesUsername for the user
first_nameYesFirst name of the user
last_nameYesLast name of the user
emailYesEmail address of the user
titleNoJob title of the user
departmentNoDepartment the user belongs to
managerNoManager of the user (sys_id or username)
rolesNoRoles to assign to the user
phoneNoPhone number of the user
mobile_phoneNoMobile phone number of the user
locationNoLocation of the user
passwordNoPassword for the user account
activeNoWhether the user account is active

Implementation Reference

  • The main handler function that implements the create_user tool logic: builds user data, POSTs to ServiceNow sys_user table, handles role assignments, returns UserResponse.
    def create_user(
        config: ServerConfig,
        auth_manager: AuthManager,
        params: CreateUserParams,
    ) -> UserResponse:
        """
        Create a new user in ServiceNow.
    
        Args:
            config: Server configuration.
            auth_manager: Authentication manager.
            params: Parameters for creating the user.
    
        Returns:
            Response with the created user details.
        """
        api_url = f"{config.api_url}/table/sys_user"
    
        # Build request data
        data = {
            "user_name": params.user_name,
            "first_name": params.first_name,
            "last_name": params.last_name,
            "email": params.email,
            "active": str(params.active).lower(),
        }
    
        if params.title:
            data["title"] = params.title
        if params.department:
            data["department"] = params.department
        if params.manager:
            data["manager"] = params.manager
        if params.phone:
            data["phone"] = params.phone
        if params.mobile_phone:
            data["mobile_phone"] = params.mobile_phone
        if params.location:
            data["location"] = params.location
        if params.password:
            data["user_password"] = params.password
    
        # Make request
        try:
            response = requests.post(
                api_url,
                json=data,
                headers=auth_manager.get_headers(),
                timeout=config.timeout,
            )
            response.raise_for_status()
    
            result = response.json().get("result", {})
    
            # Handle role assignments if provided
            if params.roles and result.get("sys_id"):
                assign_roles_to_user(config, auth_manager, result.get("sys_id"), params.roles)
    
            return UserResponse(
                success=True,
                message="User created successfully",
                user_id=result.get("sys_id"),
                user_name=result.get("user_name"),
            )
    
        except requests.RequestException as e:
            logger.error(f"Failed to create user: {e}")
            return UserResponse(
                success=False,
                message=f"Failed to create user: {str(e)}",
            )
  • Pydantic BaseModel defining the input schema/parameters for the create_user tool.
    class CreateUserParams(BaseModel):
        """Parameters for creating a user."""
    
        user_name: str = Field(..., description="Username for the user")
        first_name: str = Field(..., description="First name of the user")
        last_name: str = Field(..., description="Last name of the user")
        email: str = Field(..., description="Email address of the user")
        title: Optional[str] = Field(None, description="Job title of the user")
        department: Optional[str] = Field(None, description="Department the user belongs to")
        manager: Optional[str] = Field(None, description="Manager of the user (sys_id or username)")
        roles: Optional[List[str]] = Field(None, description="Roles to assign to the user")
        phone: Optional[str] = Field(None, description="Phone number of the user")
        mobile_phone: Optional[str] = Field(None, description="Mobile phone number of the user")
        location: Optional[str] = Field(None, description="Location of the user")
        password: Optional[str] = Field(None, description="Password for the user account")
        active: Optional[bool] = Field(True, description="Whether the user account is active")
  • Registration of the 'create_user' tool in the get_tool_definitions() dictionary: maps tool name to (function, params class, return type, description, serialization).
    "create_user": (
        create_user_tool,
        CreateUserParams,
        Dict[str, Any],  # Expects dict
        "Create a new user in ServiceNow",
        "raw_dict",  # Tool returns raw dict
    ),
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create a new user' which implies a write operation, but doesn't describe what happens upon success (e.g., returns a user ID), failure modes (e.g., duplicate username errors), side effects (e.g., sends notifications), or permissions required. This is inadequate for a mutation tool with zero annotation coverage.

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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for its purpose.

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

Completeness2/5

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

Given the complexity (13 parameters, 4 required), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances needed for a creation tool in a system like ServiceNow. The high schema coverage helps with parameters, but other critical context 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%, with each parameter well-documented in the schema itself (e.g., 'Username for the user', 'Email address of the user'). The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.

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 clearly states the action ('Create') and resource ('new user in ServiceNow'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'create_group' or 'create_incident' beyond the resource type, nor does it specify what constitutes a successful creation versus what might fail.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., required permissions), when not to use it (e.g., for updating existing users), or refer to sibling tools like 'update_user' or 'get_user' for related operations.

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/JLKmach/servicenow-mcp'

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