Skip to main content
Glama
anythink-cloud

Anythink-MCP

Official

Roles: create

roles_create

Create a unique project role to group users; it starts with no data permissions, so grant access with roles_permissions_add, then assign it via users_invite.

Instructions

Create a new role. Adds a role with no entity permissions yet, so its users can't reach any data until you grant actions with roles_permissions_add. Then give it to people by passing its id as role_id to users_invite. Role names must be unique in the project.

Input Schema

NameRequiredDescriptionDefault
nameYesRole name
descriptionNoOptional description

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.27

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is covered. The description adds non-obvious behavioral facts beyond that: a freshly created role has no entity permissions and its users cannot reach any data, and role names must be unique within the project. It stops short of saying what happens on a duplicate name or what the response contains, so it is not a full 5.

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?

Four short sentences, zero filler, and the core action is front-loaded before the sequencing and constraint details. Every sentence carries distinct information.

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?

No output schema exists, and the description implies (but does not state) that the created role's id is what gets passed to `users_invite`. For a two-parameter create tool, purpose, prerequisites, follow-ups and the uniqueness constraint are all covered; only the return payload is left implicit.

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% (both `name` and `description` documented), so the baseline is 3. The description earns an extra point by adding a real constraint on `name` that the schema does not state: names must be unique in the project. It says nothing extra about `description`.

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?

Opens with a specific verb+resource ('Create a new role') and immediately differentiates itself from siblings by describing the state it produces (a role with no entity permissions), which separates it from roles_permissions_add and roles_delete. An agent can select it without opening the schema.

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?

Gives an explicit ordered workflow: create the role, then grant actions with `roles_permissions_add`, then assign it via `users_invite` with its id as role_id. Both the alternative and the downstream steps are named with the condition that selects them.

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