Skip to main content
Glama

elaichi__member__set_roles

Set the single role one member holds. A member holds exactly ONE role in an organization, so this is a WHOLESALE REPLACE: role_ids must be an array of exactly one role id, and that role becomes their entire access. There is no way to add a role alongside an existing one — "also give Bob the admin role" means Bob stops being whatever he was and becomes an admin, so confirm that with the user before calling. If they need a mix of two roles’ permissions, the answer is a custom role holding both (role.create), not two assignments. Resolve role ids with role.list first. Takes effect on the member’s next request. You cannot assign a role that carries a permission you do not hold yourself, and you cannot re-role a member who holds permissions you lack. Returns the updated membership, including user: { id, name, email }, so you can confirm out loud whose role changed. To change what a role means for everyone who holds it, use role.update instead; to remove the person from the organization entirely, member.delete. NOT CALLABLE FROM ANY AI SURFACE, in-app agent or MCP: handing somebody a role needs step-up reauthentication (confirming it is really you), which neither surface can ask for, so every call from here is refused. Say what needs doing and tell the user to do it in Settings → People in the Elaichi app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe member’s USER id (`usr_…`) from member.list.
role_idsYesExactly one role id (`role_…`, from role.list). It replaces the member’s current role; a member cannot hold two.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations are minimal (all false). The description compensates fully: explains replace semantics, effect on next request, permission constraints (cannot assign roles with permissions you lack), re-role restrictions, return value, and the critical fact that it is NOT callable from AI surfaces due to reauthentication. No contradiction with annotations.

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?

While lengthy, every sentence adds critical information: main purpose, constraints, alternatives, prerequisites, effects, return value, and the not-callable warning. The structure is logical and front-loaded with the core purpose. No filler.

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

Completeness5/5

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

For a complex tool with security and semantic nuances, the description covers all necessary context: what, when, why not, how, prerequisites, side effects, and return value. Nothing an agent needs to know is missing.

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?

Schema coverage is 100%, but the description adds significant meaning: role_ids must be exactly one and replaces the existing role, and id must come from member.list. It also advises resolving via role.list. This goes beyond the schema's simple descriptions.

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: 'Set the single role one member holds.' It immediately clarifies it's a wholesale replace and differentiates from role.update and member.delete. This is unambiguous and distinguishes it from siblings.

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

Usage Guidelines5/5

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

Provides explicit when-to-use, when-not-to-use with alternatives: custom role for mixed permissions, role.update for changing role meaning, member.delete for removal. Also instructs to resolve role ids via role.list and to confirm with the user before calling. No ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources