Skip to main content
Glama

Assign user to a specific role

action1_create_role_user
Destructive

Assigns a user to a specific role using role and user IDs, with dry-run preview by default and explicit YES confirmation before execution.

Instructions

Assign user to a specific role. Assigns user to a role specified by its ID. Perm: assign_roles.

Input Schema

NameRequiredDescriptionDefault
confirmNoRequired to execute. Exact string "YES".
dry_runNoDefault true (preview). Set false to execute.
role_idYesProvide a specific role ID.
user_idYesProvide a specific user ID.

Output Schema

NameRequiredDescriptionDefault
idNo
toolNo
typeNo
statusNo
dry_runNo
would_sendNo
user_messageNo
developer_messageNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.6.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / additionalProperties
      Previous value: -trueNew value: +{}
    • addedOutput schema / properties / developer_message
      Added value: +{}
    • addedOutput schema / properties / dry_run
      Added value: +{}
    • addedOutput schema / properties / id
      Added value: +{}
    • addedOutput schema / properties / status
      Added value: +{}
    • addedOutput schema / properties / tool
      Added value: +{}
    • addedOutput schema / properties / type
      Added value: +{}
    • addedOutput schema / properties / user_message
      Added value: +{}
    • addedOutput schema / properties / would_send
      Added value: +{}
  2. First observedv0.5.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is known. The description adds the required permission, which is genuine value, but stays silent on the preview-by-default behavior (dry_run defaults true) beyond what the schema already documents.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and short, but the second sentence largely restates the first ('Assigns user to a role specified by its ID') rather than adding information; only the permission clause earns its place.

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?

With annotations, a 100% documented 4-param schema and an output schema, the essentials are covered. Still, the description omits the mutation's operational gate (dry_run preview plus confirm=YES) and the permission's effect on role scope, leaving a gap for a destructive write tool.

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% and all four parameters are documented there, so the baseline is 3. The description only restates that the role is identified by ID and adds nothing on role_id format, user_id format, or interaßction with confirm/dry_run.

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?

States a specific verb and resource ('Assign user to a specific role') plus the permission gate ('Perm: assign_roles'). It is distinguishable from sibling role tools like delete_role_user and list_role_users by the 'assign' verb, though it does not name those siblings explicitly.

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

Usage Guidelines3/5

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

Usage context is implied by the name and the stated permission prerequisite ('assign_roles'), which tells the agent a required capability. It gives no explicit when-to-use guidance and no mention of the dry_run/confirm two-step that governs actually executing the assignment.

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