Skip to main content
Glama

create_permission_group

Creates a new permission group for a specified target in a workspace.

Instructions

Create a new permission group on a target. Returns the new group ID.

workspace_id: target workspace ID — get available IDs from list_workspaces()
target_type: "HubProfile" or "Workspace"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
target_idYes
target_typeYes
workspace_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.18

TDQS

B3.3/5.0
Behavior3/5

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

Annotations (readOnlyHint=false, destructiveHint=false) already establish this as a non-destructive write, and the description adds the behavioral detail 'Returns the new group ID.' No contradictions exist, but error behavior (invalid target_type, duplicate name) and idempotency are not disclosed — acceptable for a create, yet not fully transparent.

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?

Two tight sentences plus two one-line parameter hints. The purpose is front-loaded, and every sentence carries information — no filler, no redundancy with the schema or annotations.

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?

The output schema presence plus the return-value note ('Returns the new group ID') covers the outcome, and target types are specified. However, the undocumented name and target_id parameters leave a real gap in what a caller must supply, and no error/edge-case behavior is mentioned.

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

Parameters2/5

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

Schema coverage is 0% — none of the 4 parameters have schema-level descriptions. The description text explains workspace_id and target_type, but name and target_id are entirely unexplained; target_id's meaning (the hub profile or workspace being targeted) is ambiguous without cross-referencing. Less than half of the required parameters receive meaningful documentation.

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?

'Create a new permission group on a target' uses a specific verb and resource, and the 'on a target' qualifier distinguishes it from the sibling create_* tools. It clearly separates from get/update/delete_permission_group siblings, leaving little ambiguity about the operation.

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 useful context — target_type values ('HubProfile' or 'Workspace') and a pointer to list_workspaces() for workspace IDs — but never states when to use this vs. alternatives like give_permission (direct grant) or add_users_to_permission_group (populating a group after creation). The when-not-to-use guidance is implied rather than explicit.

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