Skip to main content
Glama

list_projects

List all indexed firmware projects with statistics to find project names or IDs, then inspect builds or health for a chosen project.

Instructions

List all indexed firmware projects with their statistics.

Read-only. No side effects. Use it to find another project; call get_project_status for the builds and the health of one project.

indexed_at and first_indexed_at are UTC, in "YYYY-MM-DD HH:MM:SS" format — the same format that get_project_status returns. indexed_at is the time of the newest build.

A project of several builds gets no counts here (symbol_count, file_count, description and analysis are None): a file that two images compile is in the index of each, thus a sum counts shared code once for each build. get_project_status gives the counts of each build.

analysis holds the project and vendor counts only. For the model, analyze_vendor, and complete fields, call get_build_info for that build.

Args: project_root: Project root whose config names the index directory (index.db_dir). Omitted, the global config does. project: Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.

Returns: list of dicts, each with: project_id, name, root_path, build_system, symbol_count, file_count, indexed_at (str — UTC), description (str), first_indexed_at (str — UTC), schema_version, current_schema, reindex_needed (bool — the schema is outdated, the compile_commands.json of a build changed or is missing, or a build holds rows of an older row format; each (variant, image) build counts), status (str — "ready" or "reindex_needed"), db (path to SQLite database file), build_count (int — number of builds, each a (variant, image) pair), analysis (dict — LLM-analysis coverage {project: {analyzed, skipped, total}, vendor: {analyzed, skipped, total}}, or None when no build is indexed).

When no project has an index, the result is a single dict with an
``info`` key.  When fw-context cannot read a database, the result
holds a dict with ``db`` and ``error`` keys for that file.

Input Schema

NameRequiredDescriptionDefault
projectNoProject name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.
project_rootNoProject root whose config names the index directory; pass it to distinguish multiple indexed projects that keep separate index directories. Omitted = the global config. Every project in that directory is listed. This field also accepts a project name or a project_id, but project is the clear field for those.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.32.1
    • changedInput schema / properties / project_root / description
      Previous value: -"Project root. Auto-detected if omitted. Pass to distinguish multiple indexed projects. This field also accepts a project name or a project_id, but project is the clear field for those."New value: +"Project root whose config names the index directory; pass it to distinguish multiple indexed projects that keep separate index directories. Omitted = the global config. Every project in that directory is listed. This field also accepts a project name or a project_id, but project is the clear field for those."
  2. Changed3 schema fields changedv0.30.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / project
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.",
      +  "title": "Project"
      +}
    • changedInput schema / properties / project_root / description
      Previous value: -"Project root. Auto-detected if omitted. Pass to distinguish multiple indexed projects."New value: +"Project root. Auto-detected if omitted. Pass to distinguish multiple indexed projects. This field also accepts a project name or a project_id, but project is the clear field for those."
  3. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden. It declares 'Read-only. No side effects.' and thoroughly explains return semantics, edge cases (no indexed projects, unreadable databases), and why counts are None for multi-build projects. This is rich transparency beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and usage, but it is long and includes detailed Args and Returns sections that duplicate the input schema and output schema. While every section is organized, several sentences do not earn their place given the structured fields already provided.

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 and the existence of an output schema, the description is complete enough for an agent to call it correctly. It covers purpose, usage, parameters, return behavior, and edge cases, leaving no critical gap for invocation.

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%, so the schema already documents both parameters. The Args section largely repeats the schema text, adding only '(index.db_dir)' for project_root. Baseline 3 is appropriate because the description does not add significant meaning beyond the schema.

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?

States a specific verb and resource: 'List all indexed firmware projects with their statistics.' Distinguishes from sibling tools by naming get_project_status for single-project builds and health. An agent can tell what this tool does without opening the schema.

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?

Explicitly says 'Use it to find another project' and directs the agent to get_project_status for builds and health, and to get_build_info for model/analyze_vendor/complete fields. Clear alternatives and conditions are provided.

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