Skip to main content
Glama
MotleyAI

SLayer

by MotleyAI
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

query_nested

Run multi-stage queries as a DAG where each stage can reference prior outputs as source models. Solves chained analytics where one query's result feeds the next.

Instructions

Run a multi-stage query as a DAG. Use this when one stage depends on the output of another.

queries is a list of query dicts forming a DAG. Each entry has the same shape as the regular query tool's arguments (source_model, measures, dimensions, filters, time_dimensions, order, limit, offset, whole_periods_only) plus an optional name. Stages reference each other by name via source_model: "<sibling_name>" or joins.target_model.

Order doesn't matter — the engine auto-sorts so every stage appears after the siblings it references. The last entry of the input is always the entry point / DAG root (its result is what's returned); only the non-final entries are reordered. Every non-final entry must have a name. Cycles, self-references, and a non-final stage referencing the root are rejected with a clear error. Stages that aren't reachable from the root are accepted as utility sub-queries — they're silently dropped from the emitted SQL.

Args: queries: Ordered list of stage dicts. Earlier stages must be named; the last stage is the one whose rows return. variables: Variable values for {var} placeholder substitution in filters. Runtime kwarg precedence: runtime > stage.variables > outer query.variables > model.query_variables. show_sql: When true, include the generated SQL in the response. dry_run: When true, generate the SQL without executing it. explain: When true, run EXPLAIN ANALYZE and return the plan. format: markdown (default), json, or csv.

Example: queries=[ {"name": "monthly", "source_model": "orders", "measures": [{"formula": ":count"}, {"formula": "revenue:sum"}], "time_dimensions": [{"dimension": "created_at", "granularity": "month"}]}, {"source_model": "monthly", "measures": [{"formula": ":count"}]} ]

For a single-stage query, prefer the regular query tool — its typed arguments give a more discoverable schema.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNomarkdown
dry_runNo
explainNo
queriesYes
show_sqlNo
variablesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.10.0

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 fully carries the behavioral burden. It discloses engine auto-sorting, the last entry being the DAG root, required names for non-final stages, rejection of cycles/self-references/root references, silent dropping of unreachable stages, variable precedence, and the effects of `show_sql`, `dry_run`, and `explain`.

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 appropriately so for a complex DAG-based tool. It is front-loaded with the core purpose, then structured into semantics, arguments, an example, and an alternative-tool recommendation. Every section adds useful information without fluff.

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?

The description is complete for a tool of this complexity: it covers DAG semantics, ordering, naming rules, error cases, variable precedence, flags, formats, and includes an end-to-end example. An output schema exists, so detailed return-value documentation is not required from the description.

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%, so the description must compensate, and it does. Each parameter is explained, including defaults, placeholder substitution, precedence, and format options. It also explains that each query dict follows the same shape as the regular `query` tool's arguments and provides a concrete example.

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 line clearly states the tool's function: 'Run a multi-stage query as a DAG.' It also states the exact use case—when one stage depends on another—which distinguishes it from the sibling `query` tool for single-stage queries.

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 says when to use this tool: 'Use this when one stage depends on the output of another.' It also gives an explicit alternative and exclusion: 'For a single-stage query, prefer the regular query tool—its typed arguments give a more discoverable schema.'

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MotleyAI/slayer'

If you have feedback or need assistance with the MCP directory API, please join our Discord server