Skip to main content
Glama

query_region

Retrieve shapes, text labels, and child instances overlapping a bounding box in a KLayout layout. Returns stable IDs for follow-up measurement, analysis, or rendering.

Instructions

Return shapes, text labels, and child instances overlapping a box.

Each returned shape has a session-stable id (e.g. shp_1a2b3c4d). Pass these ids to measure_geometry, analyze_waveguide, or render_view annotations. Results are sorted deterministically; truncation reports how many items the limits dropped.

Args: session_id: Session returned by open_layout. box: Query window in microns: {"left", "bottom", "right", "top"}. cell: Cell to query. Defaults to the session's selected top cell. layers: Optional [{"layer": int, "datatype": int}] filter. Defaults to all layers. hierarchy_mode: top for shapes placed directly in the cell, or recursive / flattened to include shapes from child cells transformed into the cell's coordinates. max_shapes: Maximum number of shapes to return. max_instances: Maximum number of child instances to return. max_texts: Maximum number of text labels to return.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boxYes
cellNo
layersNo
max_textsNo
max_shapesNo
session_idYes
max_instancesNo
hierarchy_modeNorecursive

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / max_texts
      Added value: +{
      +  "default": 200,
      +  "title": "Max Texts",
      +  "type": "integer"
      +}
  2. First observedv0.2.3

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries full behavioral burden and handles it well: it discloses session-stable id semantics, deterministic result ordering, and that truncation reports how many items the caps dropped. It stops short of confirming read-only safety or performance characteristics of recursive queries, but the substantive behaviors are covered.

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?

The purpose sentence and id-routing note are front-loaded, then the Args block. The block is long, but with 0% schema coverage each line is load-bearing; the phrasing is compact and free of repetition.

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?

For an 8-parameter nested-schema query tool, everything an agent needs is present: required params, formats, enum-like values, defaults, coordinate system, and truncation reporting. An output schema exists, yet the description still usefully explains the id contract that downstream tools depend on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are 8 parameters, so the description must compensate, and it does: every argument gets meaning, including box as microns with an explicit key layout, the layers filter shape, hierarchy_mode's top/recursive/flattened semantics, defaults, and the three truncation caps.

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?

The opening sentence names a concrete verb (return) and three specific resources (shapes, text labels, child instances) scoped by an overlap box. The mention of handing ids to measure_geometry/analyze_waveguide/render_view makes clear this is the discovery step, not a measurement or rendering tool, distinguishing it from those siblings.

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?

It establishes the workflow context: session_id comes from open_layout, and returned ids feed measure_geometry, analyze_waveguide, or render_view. It does not state when to use this versus a narrower sibling query or any exclusion conditions, but the downstream routing is explicit and useful.

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