Skip to main content
Glama
Sign In
OpenProject CE MCP

OpenProject CE MCP

by jtauschl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_project_memberships

Read-onlyIdempotent

Lists memberships for a project, returning principal and role names with optional field selection and paging. Use it to see who belongs to a project and in what roles.

Instructions

List memberships for a project, including principal and role names.

Input Schema

NameRequiredDescriptionDefault
limitNoPage size, capped at OPENPROJECT_MAX_PAGE_SIZE.
offsetNo1-based page number; pass the previous result's next_offset.
selectNoFields to return; a requested unset field comes back as null. Allowed: can_update, can_update_immediately, created_at, id, principal_id, principal_name, project_id, project_name, role_ids, role_names, updated_at.
projectYesProject identifier, id, or name; a unique part of a name or identifier also matches.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.4
  2. Removedv0.4.0
  3. Changed1 schema field changedv0.3.7
    • addedInput schema / additionalProperties
      Added value: +false
  4. Addedv0.3.3
  5. Removedv0.3.0
  6. Changed1 schema field changedv0.2.3
    • changedOutput schema / (root)
      Previous value: -{
-  "$defs": {
-    "MembershipSummary": {
-      "properties": {
-        "can_update": {
-          "title": "Can Update",
-          "type": "boolean"
-        },
-        "can_update_immediately": {
-          "title": "Can Update Immediately",
-          "type": "boolean"
-        },
-        "id": {
-          "title": "Id",
-          "type": "integer"
-        },
-        "principal_id": {
-          "anyOf": [
-            {
-              "type": "integer"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "title": "Principal Id"
-        },
-        "principal_name": {
-          "anyOf": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "title": "Principal Name"
-        },
-        "project_id": {
-          "anyOf": [
-            {
-              "type": "integer"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "title": "Project Id"
-        },
-        "project_name": {
-          "anyOf": [
-            {
-              "type": "string"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "title": "Project Name"
-        },
-        "role_ids": {
-          "items": {
-            "type": "integer"
-          },
-          "title": "Role Ids",
-          "type": "array"
-        },
-        "role_names": {
-          "items": {
-            "type": "string"
-          },
-          "title": "Role Names",
-          "type": "array"
-        },
-        "url": {
-          "title": "Url",
-          "type": "string"
-        }
-      },
-      "required": [
-        "id",
-        "principal_id",
-        "principal_name",
-        "project_id",
-        "project_name",
-        "role_ids",
-        "role_names",
-        "can_update",
-        "can_update_immediately",
-        "url"
-      ],
-      "title": "MembershipSummary",
-      "type": "object"
-    }
-  },
-  "properties": {
-    "count": {
-      "title": "Count",
-      "type": "integer"
-    },
-    "results": {
-      "items": {
-        "$ref": "#/$defs/MembershipSummary"
-      },
-      "title": "Results",
-      "type": "array"
-    }
-  },
-  "required": [
-    "count",
-    "results"
-  ],
-  "title": "MembershipListResult",
-  "type": "object"
-}New value: +null
  7. First observedv0.2.2

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds a useful return-content hint (principal and role names are included, which matters since there is no output schema) but says nothing about pagination behavior beyond what the schema's limit/offset fields already document.

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?

A single front-loaded sentence with no filler; the purpose and the returned content are both delivered immediately. It is arguably slightly thin for a list tool with pagination and field selection, but nothing is wasted.

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?

For a read-only list tool with full schema coverage and annotations, the essentials are present. The remaining gaps – how it differs from get_membership, and any note on paging through large membership sets – are the main things an agent would still want.

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 description coverage is 100% – project identifier matching, select fields, and 1-based offset are all documented in the schema. The description adds no additional meaning about the project argument or how select filtering interacts with the listed principal/role names, so the baseline of 3 applies.

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 and resource ("List memberships for a project") and adds that results carry principal and role names, which tells an agent what it gets back. It does not differentiate from the closely related get_membership or get_project_admin_context siblings, so an agent must infer the distinction.

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?

Usage is only implied: the description scopes the call to one project, so an agent can infer this is for enumerating a project's members. It names no alternatives (get_membership for a single record, list_roles for role lookups) and states no when-not conditions.

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