Skip to main content
Glama

list_projects

Read-onlyIdempotent

List projects with stable pagination, selecting lean identity or detailed stats for graph sizes and counts.

Instructions

List projects with stable paging. Identity is lean; stats adds graph sizes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
detailNostats adds node/edge/database-size counts.identity
formatNotree
offsetNo
metadata_onlyNoCompatibility: omit counts, size, and branch.
include_detailsNoAlias for detail=stats: include branch, node/edge counts and database size. Slower.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.11.0
    • addedInput schema / properties / detail
      Added value: +{
      +  "default": "identity",
      +  "description": "stats adds node/edge/database-size counts.",
      +  "enum": [
      +    "identity",
      +    "stats"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / format
      Added value: +{
      +  "default": "tree",
      +  "enum": [
      +    "tree",
      +    "json"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / include_details
      Added value: +{
      +  "default": false,
      +  "description": "Alias for detail=stats: include branch, node/edge counts and database size. Slower.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 50,
      +  "maximum": 500,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / metadata_only
      Added value: +{
      +  "default": false,
      +  "description": "Compatibility: omit counts, size, and branch.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "minimum": 0,
      +  "type": "integer"
      +}
  2. Changed1 schema field changedv0.10.4
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "type": "object"
      -}New value: +null
  3. Addedv0.10.0
  4. Removedv0.9.0
  5. First observedv1.0.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare the operation read-only and idempotent. The description adds meaningful behavioral context by highlighting 'stable paging' and explaining that identity mode is lean while stats mode adds graph sizes, which goes beyond the structured annotations.

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?

Two short sentences deliver the core purpose, a key behavioral guarantee, and the main detail-mode tradeoff with no wasted words. The content is front-loaded and easy to scan.

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 tool with six parameters and no output schema, the description is brief but somewhat incomplete. It covers purpose and a few parameter semantics, but it does not explain response shape, how paging behaves beyond 'stable', or the format/metadata_only compatibility options. It is adequate but leaves meaningful gaps.

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 only 50%, so the description must compensate for undocumented parameters. It adds value by clarifying that the detail parameter controls whether graph sizes are included. However, it says nothing about limit, offset, format, metadata_only, or include_details beyond what the schema already provides, leaving several parameters unexplained.

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?

The description clearly states the action and resource: 'List projects'. The mention of 'stable paging' and the detail-mode distinction adds useful specificity. It does not explicitly differentiate from sibling tools, but the purpose is unambiguous.

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?

The description implies when to use the tool by saying it lists projects with stable paging, and it gives some guidance on choosing between identity and stats detail. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions, leaving usage context mostly implicit.

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