Skip to main content
Glama

List projects

list_projects
Read-onlyIdempotent

Fetch OpenProject projects page by page with filters for search, parent, and phase. Converts project names to IDs, lists sub-projects, and flags off-track status.

Instructions

List projects, filtered server-side, one page at a time.

Use this to turn a project name into the id or identifier that every other tool consumes, to enumerate the sub-projects of a parent, or to review which projects are off track. It is the id-producing path for every project_id parameter in this server.

Returns the standard list envelope: items of {id, identifier, name, active, public, parent, status_code, workspace_type} plus pagination with total/page/page_size/has_more. Nothing is truncated silently — page explicitly until has_more is false.

Pitfalls: search matches name and identifier only (not descriptions); parent_id returns direct children, so a deep hierarchy needs one call per level; status_code is a code such as on_track, never a translated label. On OpenProject 17.x this listing deliberately mixes plain projects with programs and portfolios — workspace_type says which each row is. in_phase tests phase dates ("which projects are in Executing today"), so projects whose phases carry no dates never match it.

For a single project's description and status explanation use get_project. For the types, versions, categories and time-entry activities valid inside a project use get_project_metadata. To list a project's work packages use list_work_packages(project=...).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number.
activeNotrue (default) lists active projects, false lists only archived ones, null lists both. Archived projects are read-only in OpenProject.
searchNoCase-insensitive substring matched against the project name AND its identifier. Descriptions are not searched. Omit to list everything the filters allow.
sort_byNoServer-side sort, e.g. [["name", "asc"], ["created_at", "desc"]]. Allowed keys: active, created_at, id, identifier, name, public, updated_at. Unknown keys are rejected with the allowed set listed.
in_phaseNoRestrict to projects whose named phase covers a date (today unless phase_on_date says otherwise). Accepts a definition id or name from list_project_phase_definitions. Requires OpenProject 16.1+.
fetch_allNoAggregate every page into one result instead of returning page 1. Capped at 500 items with a note when the cap bites; mutually exclusive with page.
page_sizeNoRecords per page (max 100); the instance may clamp it lower and the returned pagination reports what actually came back.
parent_idNoNumeric id or identifier of a parent project; returns its DIRECT children only, not the whole subtree. Ids come from a previous list_projects call.
phase_on_dateNoISO date (YYYY-MM-DD) the in_phase filter should test instead of today. Only valid together with in_phase.
favorites_onlyNoRestrict to projects the authenticated user has favorited. Instances that predate project favorites reject this filter with a 400.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: the standard list envelope, explicit pagination ('Nothing is truncated silently — page explicitly until has_more is false'), and pitfalls (search scope, direct-children semantics, status_code codes, workspace_type mixing, in_phase date semantics).

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?

The description is long but every section earns its place: overview, use cases, return envelope, pitfalls, and explicit alternatives. It is front-loaded with the core purpose and structured logically, avoiding fluff. For a tool with 10 parameters and significant edge cases, this length is justified.

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?

Given the tool's complexity (10 parameters, many edge cases, and many sibling tools), the description is remarkably complete. It covers the result envelope, pagination behavior, parameter interplay, version-specific behavior (OpenProject 17.x), and redirects to relevant alternatives. An output schema exists, so return-value detail is appropriately left to the schema.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining behavioral implications of specific parameters: 'parent_id returns direct children, so a deep hierarchy needs one call per level', 'in_phase tests phase dates', and that search ignores descriptions. These go beyond the raw schema text, earning a 4.

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 states a specific verb+resource ('List projects') and clearly differentiates from siblings by positioning this tool as the id-producing path for every project_id, and by naming alternatives (get_project, get_project_metadata, list_work_packages). It also enumerates concrete use cases (name→id, enumerate sub-projects, review off track).

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?

Explicit when-to-use guidance is provided ('Use this to turn a project name into the id...'), and exclusions are named with alternative tools ('For a single project's description... use get_project; For the types... use get_project_metadata; To list a project's work packages use list_work_packages'). This gives clear steering versus alternatives.

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