Skip to main content
Glama
BarnieBarnie

schematic-architect

by BarnieBarnie

list_designs

Lists designs open in the current session with their palette, size, and block count, so you can identify and compare available builds.

Instructions

The designs open in this session, with their palette, size and block count.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries the disclosure burden. It usefully reveals that results are scoped to the current session and that each entry carries palette, size, and block count, but it never states that the operation is a read-only listing or how many designs may be returned.

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?

A single short sentence conveys scope and returned fields with no filler. It is front-loaded and efficient, though the verbless fragment style is slightly less actionable than an explicit 'List...' phrasing.

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 parameters and an output schema documenting the return shape, the description only needs to establish scope and content, which it does. The session-versus-saved distinction is implicit rather than spelled out, a minor gap.

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?

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies for a correctly parameter-free definition.

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 names the resource (designs open in this session) and the exact fields returned (palette, size, block count), which distinguishes it from siblings like new_design or open_schematic. It lacks an explicit verb, but the noun phrase is unambiguous about what the tool enumerates.

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

Usage Guidelines2/5

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

There is no explicit statement of when to call this versus alternatives such as open_schematic or new_design. The phrase 'in this session' hints at the scope, but the agent is left to infer that this is the enumeration step before opening or modifying a design.

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