Skip to main content
Glama
openl-tablets

OpenL MCP Server

Official
by openl-tablets
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

List Projects

openl_list_projects
Read-onlyIdempotent

List and filter Studio projects by repository, status, name, author, branch, tags, and sort with paginated results. Get project names, status, and projectId for use with other tools.

Instructions

List projects with the Studio filters for repository, status, dependency, name, author, branch, tags, sorting, and response expansions. Results are paginated (default 50, maximum 200): when a complete inventory is required, follow pagination.has_more and call again with pagination.next_offset until has_more is false. Returns project names, status (OPENED/CLOSED), metadata, and a convenient 'projectId' field from API to use with other tools. For local-only projects, do not pass repository filter 'local' (it may fail); list every page without that filter and filter results by repository === 'local' client-side. For such projects, open/save/close do not work; table/rule/test tools work without opening. IMPORTANT: The 'projectId' is returned exactly as provided by the API and should be used without modification. Pass either the id or name from openl_list_repositories() — both are accepted (case-insensitive). Do not invent example values; call openl_list_repositories() first if not in context. Use this to discover and filter projects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoProject name filter (partial, case-insensitive).
sortNoField used to sort the returned page.
tagsNoFilter by project tags. Tags must be prefixed with 'tags.' in the query string (e.g., tags.version='1.0', tags.environment='production'). This is handled automatically by the API client - provide as object with tag names as keys.
limitNo
authorNoLast-modifying author filter (partial, case-insensitive).
branchNoBranch filter (partial, case-insensitive).
offsetNo
statusNoFilter by project status.
includeNoOptional response expansions and listing behavior from the Studio API.
dependsOnNoReturn projects that depend on this project identifier.
repositoryNoFilter by repository name (display name, not ID). Use the 'name' field from openl_list_repositories() response (e.g., if list_repositories returns {id: 'design-repo', name: 'Design Repository'}, use 'Design Repository' here, NOT 'design-repo'). Omit to show projects from all repositories.
response_formatNoResponse format: 'json' for structured, round-trippable data (default), 'markdown' for human-readable output, 'markdown_concise' for a brief summary (1-2 paragraphs), or 'markdown_detailed' for full details with contextjson

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed10 schema fields changedv1.2.0
    • addedInput schema / properties / author
      Added value: +{
+  "description": "Last-modifying author filter (partial, case-insensitive).",
+  "type": "string"
+}
    • addedInput schema / properties / branch
      Added value: +{
+  "description": "Branch filter (partial, case-insensitive).",
+  "type": "string"
+}
    • addedInput schema / properties / dependsOn
      Added value: +{
+  "description": "Return projects that depend on this project identifier.",
+  "type": "string"
+}
    • addedInput schema / properties / include
      Added value: +{
+  "description": "Optional response expansions and listing behavior from the Studio API.",
+  "items": {
+    "enum": [
+      "summary",
+      "status",
+      "deleted",
+      "descriptor"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / name
      Added value: +{
+  "description": "Project name filter (partial, case-insensitive).",
+  "type": "string"
+}
    • changedInput schema / properties / response_format / default
      Previous value: -"markdown"New value: +"json"
    • changedInput schema / properties / response_format / description
      Previous value: -"Response format: 'json' for structured data, 'markdown' for human-readable (default), 'markdown_concise' for brief summary (1-2 paragraphs), 'markdown_detailed' for full details with context"New value: +"Response format: 'json' for structured, round-trippable data (default), 'markdown' for human-readable output, 'markdown_concise' for a brief summary (1-2 paragraphs), or 'markdown_detailed' for full details with context"
    • addedInput schema / properties / sort
      Added value: +{
+  "description": "Field used to sort the returned page.",
+  "enum": [
+    "name",
+    "status",
+    "updated"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / status / description
      Previous value: -"Filter by project status. Valid values: 'LOCAL', 'ARCHIVED', 'OPENED', 'VIEWING_VERSION', 'EDITING', 'CLOSED'."New value: +"Filter by project status."
    • changedInput schema / properties / status / enum
      Previous value: -[
-  "LOCAL",
-  "ARCHIVED",
-  "OPENED",
-  "VIEWING_VERSION",
-  "EDITING",
-  "CLOSED"
-]New value: +[
+  "LOCAL",
+  "DELETED",
+  "OPENED",
+  "VIEWING_VERSION",
+  "EDITING",
+  "CLOSED"
+]
  2. Changed1 schema field changedv1.1.0
    • removedInput schema / required
      Removed value: -[
-  "limit",
-  "offset"
-]
  3. First observedv0.0.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already indicate read-only, idempotent, and open-world behavior. The description goes well beyond that by explaining pagination mechanics (has_more/next_offset), response contents, local-only project limitations (open/save/close fail, table/rule/test work), the exactness of projectId, and the required workflow with openl_list_repositories(). No contradiction with the annotations.

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?

The description is longer than average but densely packed with necessary caveats: pagination, repository filter pitfalls, local-only behavior, and projectId handling. It is front-loaded with the core purpose and then builds logically through operational details. It could be tightened, but every sentence earns relevance given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by summarizing returned fields (project names, status, metadata, projectId) and fully specifying the pagination protocol. It also covers edge cases like local-only projects and the proper way to obtain repository values. Minor gaps remain, such as not enumerating the full status set and not detailing the effect of each include expansion, so it is strong but not exhaustive.

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 description coverage is high (83%), but the description's repository guidance directly contradicts the schema: it claims 'Pass either the id or name from openl_list_repositories() — both are accepted', while the schema explicitly says to use the display name and NOT the ID. This is actively misleading for a key parameter. The description does add useful pagination semantics and client-side local filtering, but the contradiction undermines parameter reliability.

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 opens with a specific verb and resource ('List projects') and enumerates the filtering dimensions, returning fields, and the projectId convenience field. It explicitly states the tool's role ('Use this to discover and filter projects'), setting it apart from sibling list tools that target repositories, deployments, or branches. No ambiguity about what this tool does.

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

Usage Guidelines4/5

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

The description gives clear when-to-use guidance ('Use this to discover and filter projects') and provides detailed operational conditions: paginate until has_more is false, do not pass repository filter 'local' for local-only projects, and call openl_list_repositories() first for valid repository values. It does not explicitly contrast this tool with close siblings like openl_get_project, but the intended use is nonetheless clear.

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/openl-tablets/openl-mcp'

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