Skip to main content
Glama

list_variants

Lists each indexed build's variant, image, board, config hash, symbol count, and memory map. Use it to verify what the index actually contains, including builds no longer declared in config.

Instructions

List every indexed build with its (variant, image, board) identity.

Read-only diagnostic — shows what is actually indexed, not what the config declares. Each row is one (variant, image) build with its own config_hash and symbol count. For single-project indexes this returns one row with variant/image empty.

This and get_active_build are the two tools that say what a query can choose from. Both read the index, thus a build written by fw-context index --build --variant X is listed even when config.toml no longer declares X — and resolve_build fails closed on that same fact, so the two never disagree about whether a choice must be made.

Use get_active_build for the mandatory first-call health check and the human-readable variants/images discovery; use this tool to see the per-build config_hash and symbol counts (authoritative per-build state).

Args: project_root: Project root directory. Auto-detected from CWD if omitted. 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: dict: {builds (list[dict]), multi (bool — True when the config declares variants or a build has a non-empty variant name)}.

Each build dict holds: variant (str — empty for a single-project
index), image (str — empty for a single-project index), board (str),
config_hash (str), symbol_count (int), file_count (int),
manifest_verification (str — "full" or "none"),
entry_point (str — the `ENTRY()` of the linker script of this build,
empty when no script names one),
memory (list[dict] — the `MEMORY` regions of this build:
{name, attributes, origin, length, origin_value, length_value,
file_path, line}).  `origin` and `length` are the expression the
script writes; `origin_value` and `length_value` are numbers, and
they are None for an expression that names a symbol such as
`ORIGIN(RAM) + LENGTH(RAM)`.  Empty for a build whose system
records no linker script — see the note below.

THIS is where a per-build memory map lives, not in the `images`
list of ``get_active_build``: that list holds one entry per image
NAME, and one name can belong to two variants with different
addresses.

When the project is not initialized, or has no index, the result is
{builds: [], multi: False, error (str)}.

Input Schema

TableJSON 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 directory. Auto-detected from CWD if omitted. This field also accepts a project name or a project_id, but project is the clear field for those.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 directory. Auto-detected from CWD if omitted."New value: +"Project root directory. Auto-detected from CWD if omitted. This field also accepts a project name or a project_id, but project is the clear field for those."
  2. Addedv0.25.3

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it does so thoroughly. It discloses that this is a read-only diagnostic, that it reflects the actual index rather than config, that single-project indexes return empty variant/image, that memory maps live here rather than in get_active_build, and that uninitialized projects return the {builds: [], multi: False, error: ...} shape.

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?

Long but dense and well-organized: purpose, read-only caveat, sibling differentiation, parameter docs, return shape, and cross-tool warning each earn their place. The opening line front-loads the core purpose, and the rest is structured under clear Args/Returns headings.

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?

Since there is no output schema, the description exhaustively documents the return dict, each field, the memory sub-structure, and the error case. It also covers the single-project behavior and the distinction from get_active_build's images list, leaving no obvious gap for correct 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 well. The Args section essentially repeats the schema text without adding new meaning, so the description does not raise the value beyond the schema baseline.

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?

Opens with a precise verb-object statement ('List every indexed build') and immediately scopes it to the (variant, image, board) identity. It further distinguishes itself from configuration-declared state and from get_active_build, so an agent can tell exactly what this tool returns.

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 contrasts this tool with get_active_build: use get_active_build for the mandatory first-call health check and human-readable variants/images discovery, and use this tool for per-build config_hash and symbol counts. It also explains how both relate to index state and resolve_build, giving clear selection criteria.

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