SLayer

Overview Schema Source Related Servers Discussions Admin

inspect

Look up any entity, batch, or collection by reference and type to reveal schema descriptions, sample values, and details before querying, preventing column name guesswork.

Instructions

Inspect EXACTLY one entity by reference and kind, a homogeneous BATCH when reference is a list — or the whole COLLECTION at a kind when reference is omitted / None.

A clean point-lookup: no fusion / ranking / cypher, and no bundled memories. Use search instead when you want an entity surfaced in context (with related memories and ranked neighbours).

Before using a column as a filter, projection, group-by, or join key, inspect it and read its Description: (the schema author's intent) and Sample values: (the stored literal forms — a top-N sample, indicative rather than exhaustive; build text predicates from these, never a guessed spelling). Never pick a column from its name alone.

Collection (DEV-1667): omit reference (or pass None / []) to list a whole kind. entity_type="model" lists all models grouped by datasource (compact=True: one terse line per model; compact=False: the full per-model tables). entity_type="datasource" lists all datasources. Only model / datasource support the collection view; other kinds raise. This subsumes models_summary / list_datasources.

Batch (DEV-1612): pass a list of references that all share the one entity_type. Returns one rendered block per id, in input order, each echoing its resolved canonical id (a ## <canonical> header in markdown; a JSON array under format="json"). Per-id resolution errors are isolated — one bad id does not sink the batch (in JSON it becomes a {"reference": ..., "error": ...} element). A single str keeps its byte-for-byte single output; a one-element list is still batch-framed.

Args: reference: The entity reference, or a list of references (batch). Accepts canonical forms (mydb, mydb.orders, mydb.orders.amount), bare names, join paths (orders.customers.region → resolved to the owning model), and memory:<id> for memories. Normalised via the shared resolver; the normalised canonical id is echoed in the JSON shape. entity_type: REQUIRED. One of datasource, model, column, measure, aggregation, memory. Disambiguates the 3-part canonical collision (a name shared by, e.g., a column and an aggregation) and asserts the resolved kind — a mismatch returns a detailed error. compact: When true (default): description-only for column/measure/aggregation/datasource/memory; for entity_type="model" a cheap schema skeleton (column / measure / aggregation names + join targets, zero DB calls). False returns the full render (and, for the datasource kind, a per-model skeleton for each visible model). format: "markdown" (default) or "json". num_rows: Sample-data rows for entity_type="model". Ignored (with a warning) for other kinds. show_sql: Include generated SQL for entity_type="model". Ignored (with a warning) for datasource/memory; a silent no-op for column/measure/aggregation. sections: Section subset for entity_type="model". Ignored (with a warning) for other kinds. descriptions_max_chars: Truncate description fields to this many characters. Applies to every kind.

Input Schema

TableJSON Schema

Name	Required	Default
`format`	No	markdown
`compact`	No
`num_rows`	No
`sections`	No
`show_sql`	No
`reference`	No
`entity_type`	Yes
`descriptions_max_chars`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.0Sep 3, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals the no-fusion/no-ranking/no-cypher nature, batch error isolation with per-id error elements, canonical-id echoing, ignored parameter warnings, compact-mode behavior, and the fact that collection view only works for model/datasource. This goes well beyond typical descriptions.

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?

The description is long, but it covers three modes, eight parameters, kind-specific behavior, and error semantics. It is well-structured with clear section headers for single, collection, batch, and Args. Each sentence carries useful information; the ticket references and examples are compact and relevant. The front-loading of the core behavior makes it easy to scan.

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 (three modes, eight parameters, many kind-specific exceptions), the description leaves little to inference. It explains return shaping for markdown and JSON, error isolation, canonical resolution, parameter warnings, and which entities support collection view. The presence of an output schema means the description does not need to enumerate every render field, and it focuses on the behavioral and selection guidance an agent needs.

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?

The input schema has 0% description coverage, so the Args section is the only source of parameter meaning. It fully compensates by explaining reference forms (canonical, bare, join paths, memory), the required entity_type enum, the semantics of compact, format, num_rows, show_sql, sections, and descriptions_max_chars, including which parameters are ignored for which kinds. Every parameter is given practical, non-obvious context.

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 description leads with a precise statement: Inspect exactly one entity by reference and kind, a homogeneous batch when reference is a list, or a whole collection when reference is omitted. It also distinguishes itself from siblings by naming search as the alternative for in-context lookup and noting that it subsumes models_summary and list_datasources. This is a model of clear purpose and sibling differentiation.

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?

The description explicitly states when to use the tool vs. alternatives: 'Use search instead when you want an entity surfaced in context (with related memories and ranked neighbours).' It also provides concrete guidance for collection mode, batch mode, and warns which entity types support collection. The advice to inspect columns before using them in filters/joins adds valuable use-context instructions.

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