Skip to main content
Glama

List chips

list_chips
Read-only

Retrieves the edge chips targeted by the optimizer, including each chip's SRAM and flash budget, so you can choose a valid chip name for fit checks and optimization.

Instructions

List the chips (edge devices) the optimizer targets, with each one's SRAM and flash budget for the model. Use a chip's name as chip in check_fit, lossless and optimize. Chips without budgets take yours (ram_kb, flash_kb in optimize).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_chips"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely non-obvious behavior: some chips have no budget and inherit caller-supplied ram_kb/flash_kb during optimize. It does not say whether the chip set is static or remotely sourced (relevant given openWorldHint), nor anything about ordering or caching.

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?

Two sentences, front-loaded with the purpose and followed by the actionable cross-tool guidance. The second sentence is dense with parenthetical cross-references but every clause carries information an agent needs.

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?

No output schema exists, and the description compensates by naming the returned fields (chip name plus SRAM and flash budget). Combined with the fallback-budget rule and the downstream `chip` usage, an agent has enough to call and interpret this correctly; only provenance of the chip list is unstated.

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?

Zero-parameter tool, so the baseline is 4; the description nonetheless clarifies the semantics of related parameters in sibling tools (`chip`, `ram_kb`, `flash_kb`) which the empty schema cannot. No syntax or unit details for ram_kb/flash_kb are given.

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 the chips"), disambiguates the jargon parenthetically ("edge devices"), and names the payload (each chip's SRAM and flash budget). An agent can distinguish this enumeration tool from check_fit/optimize/lossless without opening a schema.

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?

Explains how to consume the results: use a chip's name as `chip` in check_fit, lossless and optimize, and that chips lacking budgets fall back to your ram_kb/flash_kb in optimize. This effectively tells the agent to call this first to discover valid identifiers, but it never states a when-not-to-use condition or that no arguments are accepted.

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