Skip to main content
Glama
Sign In
OpenProject CE MCP

OpenProject CE MCP

by jtauschl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_my_project_access

Read-onlyIdempotent

Returns your project membership and inferred access hints, helping you confirm what you can view or manage in an OpenProject project.

Instructions

Return the current user's membership and inferred access hints for a project.

Input Schema

NameRequiredDescriptionDefault
projectYesProject identifier, id, or name; a unique part of a name or identifier also matches.

Output Schema

NameRequiredDescriptionDefault
membershipYes
project_idYes
project_nameYes
current_user_idYes
inference_basisYes
current_user_nameYes
project_identifierYes
inferred_can_edit_projectYes
inferred_is_project_adminYes
inferred_can_manage_membershipsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.4
  2. Removedv0.4.0
  3. Changed3 schema fields changedv0.3.7
    • addedInput schema / additionalProperties
      Added value: +false
    • removedOutput schema / $defs / MembershipSummary / properties / url
      Removed value: -{
-  "title": "Url",
-  "type": "string"
-}
    • changedOutput schema / $defs / MembershipSummary / required
      Previous value: -[
-  "id",
-  "principal_id",
-  "principal_name",
-  "project_id",
-  "project_name",
-  "role_ids",
-  "role_names",
-  "can_update",
-  "can_update_immediately",
-  "url"
-]New value: +[
+  "id",
+  "principal_id",
+  "principal_name",
+  "project_id",
+  "project_name",
+  "role_ids",
+  "role_names",
+  "can_update",
+  "can_update_immediately"
+]
  4. Changed2 schema fields changedv0.3.5
    • removedOutput schema / properties / project_links
      Removed value: -{
-  "items": {
-    "type": "string"
-  },
-  "title": "Project Links",
-  "type": "array"
-}
    • changedOutput schema / required
      Previous value: -[
-  "project_id",
-  "project_name",
-  "project_identifier",
-  "current_user_id",
-  "current_user_name",
-  "membership",
-  "project_links",
-  "inferred_is_project_admin",
-  "inferred_can_edit_project",
-  "inferred_can_manage_memberships",
-  "inference_basis"
-]New value: +[
+  "project_id",
+  "project_name",
+  "project_identifier",
+  "current_user_id",
+  "current_user_name",
+  "membership",
+  "inferred_is_project_admin",
+  "inferred_can_edit_project",
+  "inferred_can_manage_memberships",
+  "inference_basis"
+]
  5. Addedv0.3.3
  6. Removedv0.3.0
  7. First observedv0.2.2

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds one genuinely useful trait — that the result contains *inferred* access hints rather than raw membership rows — but says nothing about what that inference means or how reliable it is.

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?

One front-loaded sentence with no filler. It is arguably too lean for a tool with this many sibling alternatives, but nothing is padded or redundant.

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?

An output schema exists, so return values need not be explained. However, with 130+ siblings and a non-obvious "inferred" concept, one clause on when to prefer this over the membership and admin-context tools would make it complete.

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 100% and the single `project` property already documents that id, name, or a unique name/identifier fragment all match. The description adds nothing about the parameter, which is acceptable given the schema does the work.

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+resource: returns the current user's membership plus inferred access hints for a project. The "my" scoping clearly separates it from get_project and get_project_admin_context, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance and no named alternatives in a sibling list that contains obvious candidates (get_membership, list_project_memberships, get_project_admin_context). The agent must infer that this is the self-scoped access check.

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