Skip to main content
Glama
Sign In
GuardedServer

GuardedServer

by Prithv122
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

run_query

Read-onlyIdempotent

Execute catalog queries against the TPC-H sales warehouse. Specify the query name and provide necessary parameters to retrieve structured data.

Instructions

Run a catalog query by name.

params is one object mapping the query's parameter names to values; put every query parameter inside it, never next to name. Optional parameters (those with a default in describe_query) may be left out. Dates are YYYY-MM-DD and end_date is exclusive. limit caps the rows returned (default 1000, maximum 100000).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "run_query"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
limitNo
paramsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds the meaningful runtime traits of a row cap with a 100k ceiling and exclusive end_date semantics. Minor inconsistency: schema shows limit default null while the text claims 1000, which could confuse an agent about the effective default.

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?

Four short lines, front-loaded with the core action then the argument-shape warning, format rules, and limit semantics. Every sentence carries information; only the parenthetical about describe_query defaults is slightly indirect.

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?

An output schema exists, so return values need no explanation, and the description covers argument nesting, optionality, formats, and row caps — everything needed to form a correct call. The only gap, name discovery, is a convenience rather than a blocker.

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?

Schema coverage is 0%, so the description carries the full burden and largely does: it explains that `params` is a single object keyed by parameter names, warns against placing them next to `name`, permits omission of defaulted params, specifies the date format and exclusive end_date, and gives limit's default (1000) and ceiling (100000). It stops short of saying how valid `name` values or parameter keys are obtained.

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 first line gives a specific verb and resource ('Run a catalog query by name'), which clearly separates it from list_queries and describe_query. It doesn't explicitly name those siblings as the discovery path for valid query names, so differentiation is implied rather than stated.

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

Usage Guidelines3/5

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

Referencing describe_query for which parameters have defaults is a useful hook, but the description never says when to call this tool versus list_queries/describe_query, nor that queries must be discovered first. Usage is implied rather than spelled out.

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

Deploy Server

Other Tools