Skip to main content
Glama
thyn-ai

Algenta MCP

Official
by thyn-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_team_member_role

Idempotent

Assign a new organization role to a member by user ID. Requires admin key, enforces role permissions, and returns confirmation.

Instructions

Change one organization member's role by user_id (find ids with list_team_members). Requires an admin API key. Guardrails: you cannot change your own role (self_role_change_forbidden), only an owner can grant the owner role (owner_grant_forbidden), and demoting the last active owner is refused (last_owner). An unknown user_id fails with not_found. Returns the updated user_id and a confirmation message. Use remove_team_member to take the member out of the organization instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleYesNew org role for the member.
user_idYesTarget member's user_id from list_team_members.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.3
    • addedInput schema / properties / role / description
      Added value: +"New org role for the member."
    • addedInput schema / properties / user_id / description
      Added value: +"Target member's user_id from list_team_members."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this as non-read-only and non-destructive, and the description adds rich behavioral context: admin key requirement, three guardrail error conditions, the not_found failure case, and the return value. There is no contradiction with the annotations; idempotentHint is consistent with assigning a role.

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 every sentence earns its place: purpose, lookup hint, auth requirement, guardrails, error behavior, return value, and sibling alternative. The guardrails are efficiently packed into a single clause-separated sentence.

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 two-parameter mutation tool with no output schema, this description is complete: it covers inputs, auth, failure modes, return value, and relationship to a sibling tool. An agent has enough context to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters and their types, giving a baseline of 3. The description adds value by tying user_id to list_team_members and by explaining role-related restrictions beyond the enum values. This exceeds the baseline without being redundant.

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 states a specific verb ('Change'), a precise resource ('one organization member's role'), and the lookup key ('user_id'). It also names the explicit alternative, remove_team_member, which distinguishes this tool from related sibling tools like invite_team_member and remove_team_member.

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?

It clearly states when to use the tool: to change a member's role. It also provides the prerequisite (admin API key), tells the agent where to find user IDs (list_team_members), and explicitly names the alternative for removal (remove_team_member). No usage ambiguity remains.

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