Skip to main content
Glama
gobeyondidentity

@beyondidentity/mcp

Official
by gobeyondidentity
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

scim_replace_user

Replace a SCIM user entirely using PUT semantics, requiring all fields and using ETag-based optimistic locking to prevent concurrent update conflicts.

Instructions

Replace a SCIM user entirely (PUT semantics). All required fields must be provided — this is not a partial update. Uses ETag-based optimistic locking to prevent concurrent update conflicts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaNoResource metadata as defined in [RFC 7643 Section 3.1](https://www.rfc-editor.org/rfc/rfc7643#section-3.1). This attribute is only populated on responses and is ignored on requests.
nameNoDefinition of the user's name.
activeNoIndicator for the user's administrative status. If true, the user has administrative capabilities.
emailsNoThe list containing the user's emails. Important notes about email handling: - Only one email address is supported per user - The email must be marked as primary (primary: true) - If multiple email ad
schemasYesThe list of schemas used to define the user. This must contain only the core User schema ("urn:ietf:params:scim:schemas:core:2.0:User").
user_idYesID of the user.
userNameNoThe unique username of the user. The value of this field will be returned as the subject of an OIDC ID Token.
externalIdNoThe provisioning client's unique identifier for the resource. This value must be unique across all users.
displayNameNoDisplay name of the User. This name is used for display purposes.
urn_ietf_params_scim_schemas_extension_enterprise_2.0_UserNoThe Employee Number as defined in the enterprise SCIM extension

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses ETag-based optimistic locking for concurrency and the consequence of full-replacement semantics (all required fields must be supplied). It does not mention auth requirements or what happens to omitted optional fields, leaving some gaps.

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?

Two sentences, no waste, front-loads the PUT semantics and the concurrency mechanism. Every clause carries information the agent needs for correct invocation.

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 full schema coverage of a complex nested object and the absence of annotations, the description supplies the key behavioral facts (full replacement, ETag locking). It is slightly thin on auth/prerequisite details and doesn't clarify the ETag round-trip, but is otherwise sufficient for correct invocation.

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%, so the schema already documents all ten parameters thoroughly, including nested email handling and schema constraints. The description adds the meta-level rule that all required fields must be present, but no per-parameter guidance beyond what the schema provides. Baseline 3 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 (replace) and resource (SCIM user) and explicitly distinguishes full-replacement PUT semantics from partial update. This clearly separates it from scim_update_user (likely PATCH).

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?

Explicitly states 'this is not a partial update', which tells the agent when to prefer scim_update_user instead. It doesn't name the sibling tool directly, but the semantic distinction is clear enough for selection.

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