Skip to main content
Glama
rawtreedb

RawTree MCP Server

Official
by rawtreedb

Describe Table

describe-table

Retrieve a RawTree table's column structure, row and byte counts, and organization to write accurate SQL and verify schemas. Not for sampling row data.

Instructions

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

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

Returns: Table metadata and columns.

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

Input Schema

TableJSON 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.2/5.0
Behavior3/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. 'Inspect' and the return summary make the read-only, non-mutating nature clear, but there is no disclosure of permission/authorization requirements, behavior on a non-existent table, or any rate/latency characteristics. Adequate but incomplete for an annotation-free tool.

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?

Front-loaded with a bolded Purpose line, followed by tight sections for exclusion, returns, and usage. Every sentence carries distinct information and nothing is repeated.

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, the description correctly steps in with a 'Returns: Table metadata and columns' line, and covers purpose, alternatives, and usage triggers. It is complete for a read-only metadata tool, though it stops short of describing error/empty-table behavior.

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 all four parameters (table, cluster, database, organization) are already documented in the schema, including the database override default. The description adds no syntax, format, or defaulting detail beyond that, 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?

States a specific verb ('Inspect') and resource (a RawTree table), and enumerates the exact metadata returned: columns, row count, byte count, database, organization. It also explicitly distinguishes itself from run-query, so an agent can tell it apart from siblings like list-tables and run-query without opening a 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 both an explicit exclusion ('NOT for: Sampling actual row values. Use run-query for SELECT queries') and three concrete when-to-use triggers (pre-SQL field discovery, debugging missing columns, post-insert schema inspection). The alternative tool is named with the condition that selects it.

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