Skip to main content
Glama
Sign In
RawTree MCP Server

RawTree MCP Server

Official
by rawtreedb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Describe Table

describe-table

Purpose: Inspect a RawTree table's columns, row count, byte count, sorting key, database, and organization.

Instructions

Purpose: Inspect a RawTree table's columns, row count, byte count, sorting key, database, and organization.

NOT for: Sampling actual row values. Use run-query for SELECT queries.

Returns: Table metadata and columns. sorting_key is a comma-separated SQL expression string, empty when the table picks a key per part from the ingested data.

When to use:

  • You need to know available fields before writing SQL

  • A query fails because a column may not exist

  • You just inserted data and want to inspect the dynamic schema

  • You want the current sorting key before changing it with update-table

Input Schema

NameRequiredDescriptionDefault
tableYesTable name to describe.
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?

With no annotations, the description carries the behavioral burden itself and does disclose the return shape, including the non-obvious semantics of sorting_key (comma-separated SQL expression, empty when keyed per part from ingested data). It does not state side-effect freedom explicitly, nor permission/auth requirements or behavior when the table doesn't exist, so it stops short of full disclosure.

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?

Bold-labeled sections front-load purpose, exclusion, and return shape before the usage list, and each line contributes distinct information. No filler sentences; the length is proportionate to a four-parameter metadata tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description covers purpose, anti-purpose, return contents, and trigger scenarios — enough to call it correctly. It leaves out error behavior (nonexistent table, dynamic-schema edge cases) and any auth/permission notes, which keeps it short of a 5.

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% with four well-documented parameters, so the schema already does the work and baseline 3 applies. The description only glosses the table name implicitly and does not explain cluster/database/organization precedence, which is where added value would have been possible.

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?

States a specific verb ("Inspect") against a specific resource (a table's columns, row count, byte count, sorting key, database, organization), and explicitly excludes the closest sibling behavior by naming run-query for row sampling. An agent can distinguish this from run-query, list-tables, update-table, and create-table without opening any schema.

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 "NOT for" exclusion with the alternative (run-query for SELECT), plus four concrete trigger conditions (before writing SQL, after a column-not-found failure, after insert to inspect dynamic schema, before changing the sorting key). Both the when and the when-not are present, which is the top of the scale.

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