Skip to main content
Glama

recommend_root_model

Find the root source model from which every requested column or metric is reachable and get join-qualified paths for querying; if none covers all, returns partial coverage for multi-stage queries.

Instructions

Recommend the root model (query source_model) for a set of model.column / model.metric items, and give each item's join-qualified reference path from that root.

Introspects the join graph and picks the model from which every requested item is reachable (LEFT joins are directional; INNER joins traverse both ways), minimizing total join hops. The returned paths are ready to drop into a query whose source_model is the recommended root — e.g. a joined column comes back as customers.regions.name and a root-owned one as status; aggregation suffixes (:sum) are preserved.

When no single model reaches everything, root_model is null and coverage lists the best partial roots so you can split the request into a multi-stage query.

Args: items: entity references (orders.revenue, customers.name, orders.revenue:sum, bare aov for a saved metric...). data_source: optional datasource scope; when omitted, names resolve via the datasource-priority list. All items must resolve to a single datasource. root_hint: optional intended root — a bare model name or <data_source>.<model> within the resolved datasource. Honored when it reaches every item (overriding the min-hops pick, so you can force a bridge model that owns none of the items); otherwise the auto-pick is used and a warning explains why. Resolved after the datasource is determined, so it cannot pick the datasource. format: "markdown" (default) or "json".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
formatNomarkdown
root_hintNo
data_sourceNo

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

A4.8/5.0
Behavior5/5

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

No annotations are present, so the description carries full responsibility, and it delivers: it discloses join directionality rules, the min-hop objective, root_hint override semantics, and failure behavior. It also exposes the important constraint that root_hint cannot select a datasource.

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 is organized into purpose, algorithm, edge-case, and Args sections with no filler. The essential 'what it returns' and failure mode are front-loaded.

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?

Despite no annotations and an output schema that isn't shown, every decision-relevant behavior is covered: output examples, multi-stage fallback, and constraints on arguments. An agent has enough to call it correctly and interpret results.

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%, but the Args block documents all four parameters with concrete examples and nuances: item syntax variants, datasource resolution, root_hint precedence, and format defaults. This fully compensates for the empty schema descriptions.

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 opens with a specific verb ('Recommend') and resource ('root model'), and states the second output ('join-qualified reference path'). This clearly distinguishes it from query/query_nested siblings, which execute queries rather than recommend a source_model.

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 gives clear context: use when you need a source_model for a set of items, and it explains edge behavior like null root_model with coverage for partial roots and root_hint override. It does not explicitly name sibling alternatives or state when not to use it, but the intended use is unambiguous.

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

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