Skip to main content
Glama
rawtreedb

RawTree MCP Server

Official
by rawtreedb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Run Query

run-query

Execute read-only SQL queries against RawTree to return JSON rows, column metadata, statistics, and hints for safe data exploration and verification.

Instructions

Purpose: Execute a read-only SQL query against a RawTree database and return JSON rows, column metadata, statistics, and hints.

NOT for: Inserting, updating, deleting, or mutating data. RawTree validates queries as read-only and rejects unsafe statements.

Returns: RawTree's query response: meta, data, rows, statistics, and optional hints.

When to use:

  • User asks questions about data already in RawTree

  • You need to verify an insert

  • You need a quick aggregate, sample, or schema-oriented SELECT

  • You need RawTree query hints after an error

Workflow: Start with a bounded SELECT. For exploratory queries, include LIMIT and order by a time column when available.

Key trigger phrases: "query RawTree", "run SQL", "count rows", "show sample rows", "check the data"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesRead-only SQL to execute. Prefer bounded SELECT queries with LIMIT for exploration.
clusterNoRawTree cluster to use for this operation.
databaseNoOptional RawTree database override. RawTree uses the default database when omitted.
organizationNoRawTree organization containing the target cluster.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.2
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / cluster
      Added value: +{
+  "description": "RawTree cluster to use for this operation.",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / database
      Added value: +{
+  "description": "Optional RawTree database override. RawTree uses the default database when omitted.",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / organization
      Added value: +{
+  "description": "RawTree organization containing the target cluster.",
+  "minLength": 1,
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavior: queries are validated as read-only and unsafe statements are rejected, and it specifies the response components (meta, data, rows, statistics, hints) plus guidance to bound exploratory queries. It does not cover auth/permissions or rate limits, keeping it short of a 5.

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 markdown headers (Purpose, NOT for, Returns, When to use, Workflow) front-load the essentials and are easy to scan. There is mild redundancy between the 'When to use' bullets and the 'Key trigger phrases' list, but overall it is tight for the amount of useful content.

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?

With no output schema, the description must explain return values, and it does so explicitly (meta, data, rows, statistics, hints). Combined with purpose, exclusions, and workflow guidance, it gives an agent everything needed to call the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters including the optional database override and cluster/organization. The description only reinforces the bounded-SELECT advice and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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+resource ('Execute a read-only SQL query against a RawTree database') and enumerates the return shape (JSON rows, column metadata, statistics, hints). It explicitly separates itself from mutating siblings via the 'NOT for: Inserting, updating, deleting' clause, so an agent can distinguish it from insert-json/insert-from-url without opening schemas.

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?

Provides an explicit 'When to use' list plus a 'NOT for' exclusion and a workflow recommendation (start bounded, add LIMIT and order by a time column). It states both when to use and when not, leaving little to inference, though it names the exclusion by action rather than by sibling tool name.

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