RawTree MCP Server

Official

by rawtreedb

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Create Database

create-database

Purpose: Create a database in a RawTree organization and cluster.

Instructions

Purpose: Create a database in a RawTree organization and cluster.

Returns: The created database and organization context.

Behavior: s3Storage is optional. Omit it to use the cluster's default storage. When provided, it configures customer-owned database storage that all tables in the database inherit. Destination paths are optional; data and backups (each with a bucket), plus roleArn are required inside s3Storage. The API reuses the cluster's saved External ID; do not supply an identity override.

Safety: You MUST first call list-databases and confirm the exact organization, cluster, database name, and optional S3 configuration with the user. If s3Storage is provided, first call verify-database-s3-access with the identical configuration. Never reuse a successful verification after changing any s3Storage field.

Auth: Organization-admin access is required. Authorization is enforced by the RawTree API.

Reliability: This operation is not idempotent. If the response is ambiguous, call list-databases to reconcile by organization, cluster, and database name before retrying.

Input Schema

Name	Required	Description
`name`	Yes	Name of the database to create.
`cluster`	No	RawTree cluster to use for this operation.
`s3Storage`	No	Optional customer-owned S3 configuration. Omit to use the cluster's default storage.
`organization`	No	RawTree organization containing the target cluster.

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv0.4.2Oct 21, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
addedInput schema / properties / s3Storage / additionalProperties
```
Added value: +false
```
addedInput schema / properties / s3Storage / properties / backups / additionalProperties
```
Added value: +false
```

changedInput schema / properties / s3Storage / properties / backups / description

Previous value: -"Customer-owned bucket and optional key prefix for backups."New value: +"Destination for backups."

addedInput schema / properties / s3Storage / properties / backups / properties / bucket / description
```
Added value: +"Customer-owned S3 bucket."
```
addedInput schema / properties / s3Storage / properties / backups / properties / path / description
```
Added value: +"Optional object-key prefix; defaults to the bucket root."
```
addedInput schema / properties / s3Storage / properties / data / additionalProperties
```
Added value: +false
```

changedInput schema / properties / s3Storage / properties / data / description

Previous value: -"Customer-owned bucket and optional key prefix for data."New value: +"Destination for table data."

addedInput schema / properties / s3Storage / properties / data / properties / bucket / description
```
Added value: +"Customer-owned S3 bucket."
```
addedInput schema / properties / s3Storage / properties / data / properties / path / description
```
Added value: +"Optional object-key prefix; defaults to the bucket root."
```

removedInput schema / properties / s3Storage / properties / externalId

Removed value: -{
-  "description": "External ID required by the IAM role trust policy. It must exactly match the value configured in AWS.",
-  "maxLength": 1224,
-  "minLength": 2,
-  "pattern": "^[A-Za-z0-9_+=,.@:/-]+$",
-  "type": "string"
-}

changedInput schema / properties / s3Storage / properties / roleArn / description

Previous value: -"ARN of the customer IAM role that RawTree may assume to access the configured buckets."New value: +"ARN of the customer IAM role RawTree may assume."

changedInput schema / properties / s3Storage / required

Previous value: -[
-  "data",
-  "backups",
-  "roleArn",
-  "externalId"
-]New value: +[
+  "data",
+  "backups",
+  "roleArn"
+]

Addedv0.3.2Sep 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/destructive, but the description goes well beyond them: org-admin auth requirement, non-idempotency, the reconciliation procedure on ambiguous responses, the External ID reuse rule and identity-override prohibition, and the inheritance behavior of s3Storage on all tables. This is substantive context not derivable from structured fields.

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?

Bold-labeled sections (Purpose/Returns/Behavior/Safety/Auth/Reliability) make it skimmable and front-loaded, with no filler sentences. It is on the longer side, and the Returns line is largely superseded by the schema, but every other sentence carries decision-relevant information.

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?

For a non-idempotent mutation with a nested s3Storage object and no output schema, the definition still covers auth, failure recovery, optionality, and the verify-then-create prerequisite. Nothing an agent needs in order to call it safely is missing.

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 100%, so the baseline is 3; the description still adds meaning by explaining that s3Storage is optional, defaults to cluster storage, and that its contents are inherited by all tables in the database, plus which inner fields are required. It stops short of describing path/prefix semantics, which the schema already handles.

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+resource ('Create a database') scoped to an organization and cluster, which cleanly separates it from create-cluster, create-table, and delete-database among the siblings. An agent needs no further reading to know what this tool produces.

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?

Gives explicit preconditions and ordering: call list-databases and confirm org/cluster/name with the user first, and call verify-database-s3-access with an identical configuration before supplying s3Storage. It also states an exclusion — never reuse a verification after changing any s3Storage field — which is exactly the disambiguation an agent needs.

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

Create Database

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools