Skip to main content
Glama

List roles

list_roles
Read-onlyIdempotent

Retrieve OpenProject role IDs and names to supply role_ids when creating or updating memberships.

Instructions

List the roles this instance defines, with their ids.

This is the id-producing tool for create_membership.role_ids and update_membership.role_ids — role names are never accepted there. Roles are instance-wide definitions ('Member', 'Reader', 'Project admin'); a membership binds one principal to one project with a set of them.

Returns the standard list envelope with has_more: false: the role list is small and fetched in full. Each item is {id, name}, plus permissions when include_permissions=true.

Pitfalls. Role names are configurable per instance, so do not assume 'Member' exists — read the list. Some roles are not assignable to a project membership (global and work-package roles live in the same collection); the membership form rejects those with the assignable set listed. Not every OpenProject version exposes permission arrays on this endpoint: when include_permissions=true returns none, notes says so rather than pretending the roles grant nothing.

Cross-references: create_membership / update_membership consume these ids; list_memberships shows which roles are in use; list_permissions answers what the current user may do, which is the more useful question when a call just failed with 403.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
include_permissionsNoAdd each role's full permission identifier array. Off by default because those arrays are long — a dozen roles can run to thousands of tokens. Turn it on only when the question is genuinely 'what does this role allow'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sumsNoPresent only when show_sums was requested.
itemsNoThe page of results.
notesNoDegradation markers: capped aggregations, unavailable modules, …
groupsNoPresent only when group_by was requested.
paginationYesTotal/page/page_size/has_more.
Behavior5/5

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

Annotations already mark it read-only, idempotent, and non-destructive, but the description adds substantial context: the list envelope with has_more:false, the item shape, the effect of include_permissions, configurable role names, assignability restrictions, and version-dependent permission arrays. This goes far beyond annotation defaults and warns of realistic pitfalls.

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?

Well-structured with a lead sentence, a clear note on id usage, a return-format paragraph, a Pitfalls section, and a Cross-references section. Every sentence adds value, no fluff, and important details are front-loaded. Length is justified by the richness of guidance.

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?

Despite having an output schema, the description still explains the envelope and item shape. It covers the tool's role in the wider workflow, its pitfalls, and cross-references to related tools. For a single-parameter list tool, this is as complete as one could reasonably need.

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% and already describes include_permissions well, so baseline is 3. The description adds extra practical context by explaining the performance cost (thousands of tokens) and advising when to enable it, which genuinely enhances the schema's meaning. Minor gap: no mention of default false beyond schema, but that's already there.

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 clearly states it lists instance-defined roles with their IDs, using a specific verb and resource. It distinguishes itself from sibling tools by explaining its role as the id-producing tool for membership operations, making its purpose unmistakable.

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?

Explicitly frames this as the required source for role_ids in membership tools, says role names are never accepted, and names alternatives: list_memberships for usage, list_permissions for current user permissions, especially after a 403. Provides clear when-to-use and when-not-to-use guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kar-thik/openproject-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server