Skip to main content
Glama

Tommos

Change a member's role

change_a_members_role
Idempotent

Change a member's role to admin, member or viewer. An admin never changes an owner; the only Owner is never demoted; ownership is not transferred here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleYes
user_idYesThe member's user id (from list_the_team)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

With annotations already declaring the mutation as idempotent and non-destructive, the description adds real behavioral constraints: role changes apply only to non-owner members and ownership transfer is explicitly excluded. It still omits whether a permission level is required or whether the member is notified.

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

Conciseness4/5

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

Two tightly packed sentences with the core action and valid targets front-loaded. The second sentence is dense but every clause carries a real constraint, so little is wasted.

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?

For a two-parameter mutation with annotations covering safety and idempotency and no output schema, the description supplies the key scope boundaries an agent needs. Remaining gaps (invoker permissions, side effects like notifications) are minor.

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 coverage is 50%; user_id is documented in the schema, and the role enum is self-explanatory, but the description lists only admin/member/viewer while the enum also allows owner, so it neither explains the owner case cleanly nor adds syntax beyond the schema. Roughly baseline for partial 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?

States a specific verb (change) and resource (a member's role) with the target values, so an agent knows exactly what operation is performed. It does not explicitly distinguish itself from siblings like remove_a_member or invite_a_person, which keeps it short of a 5.

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?

The description gives genuine when-not guidance through scope limits (admins can't touch an owner, the sole Owner is never demoted, ownership transfer is out of scope), but it never routes the agent to an alternative tool or states prerequisites such as who may invoke it.

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