RawTree MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Create Cluster

create-cluster

Provisions a new dedicated RawTree cluster in an organization with specified replicas and vertical autoscaling, optionally using customer-owned S3 storage.

Instructions

Purpose: Provision a new RawTree dedicated cluster in an organization.

Returns: The newly created cluster, including its ID, lifecycle status, and initial resources. Provisioning continues asynchronously after the request is accepted; use get-cluster to check progress.

Behavior: The cluster starts at minimumSize and can vertically autoscale per replica up to maximumSize. The replica count remains fixed. s3Storage is optional: omit it to use RawTree-managed storage. When provided, it configures customer-owned data and backup destinations through a customer IAM role. Destination paths are optional; the buckets, roleArn, and externalId are required inside s3Storage. databaseS3Access is also optional and independent from s3Storage: provide it when databases may later use dedicated customer-owned buckets, even if the cluster keeps RawTree-managed default storage. It contains the External ID and the immutable database bucket tag; each customer database bucket must carry rawtree.com/cluster=. When both settings are supplied, their External ID values must match. The role ARN and bucket destinations for an individual database are supplied later in create-database.s3Storage.

Auth: The RawTree API requires a user access token with organization admin access. Authorization is enforced by the API.

Safety: You MUST first call list-cluster-sizes, then confirm the exact organization, name, replica count, minimum per-replica size, maximum per-replica size, vertical autoscaling behavior, and idle timeout with the user. If idleTimeoutMinutes is omitted, explain that the server default will apply. For one replica, warn that the cluster has no redundancy. If s3Storage is provided, first call verify-cluster-s3-access with the identical configuration and confirm the data and backup buckets, optional paths, role ARN, and External ID. Never reuse a successful verification after changing any s3Storage field. If databaseS3Access is provided, confirm that its External ID and immutable bucket tag are intentional and that customer database buckets will be tagged as required; this metadata does not verify or create future database buckets.

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

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	URL-friendly cluster name using letters, numbers, '_' or '-'.
`replicas`	Yes	Number of cluster replicas.
`s3Storage`	No	Optional customer-owned S3 configuration. Omit to use RawTree-managed storage. Verify the identical configuration with verify-cluster-s3-access before creation.
`maximumSize`	Yes	Maximum vertical autoscaling size returned by list-cluster-sizes. Must be at or above minimumSize in the returned catalog.
`minimumSize`	Yes	Initial and minimum vertical autoscaling size returned by list-cluster-sizes.
`organization`	Yes	Organization in which to create the cluster.
`databaseS3Access`	No	Optional independent per-database S3 capability. It may be supplied without s3Storage. Apply the databaseBucketTag to each customer-owned database bucket; if s3Storage is also supplied, externalId must match.
`idleTimeoutMinutes`	No	Minutes of inactivity before automatically pausing. Use 0 to disable idling. Omit to use the server default.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.2Sep 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only supply readOnly=false, idempotentHint=false, destructiveHint=false. The description goes well beyond: async provisioning continues after acceptance, autoscaling semantics (min/max per replica, fixed replica count), storage fallback behavior, org-admin auth requirement, and the non-idempotent retry guidance. This is substantial additive behavioral context.

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 (Purpose, Returns, Behavior, Auth, Safety, Reliability) front-load the essentials and make the dense content scannable. Given 8 parameters, nested objects, and the safety protocol, every sentence earns its place.

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 supplies the return semantics (new cluster with ID, lifecycle status, initial resources) and covers auth, safety prerequisites, and reconciliation on ambiguity. Nothing an agent needs to invoke this complex mutation correctly 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, but the description adds relational meaning the schema does not: s3Storage is optional and, when present, drives customer-owned data/backup buckets; databaseS3Access is independent of s3Storage and its externalId must match s3Storage's when both are set; per-database role ARN/destinations belong to create-database. These cross-field constraints are genuinely additive.

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 ('Provision a new RawTree dedicated cluster in an organization'), which unambiguously distinguishes it from siblings like create-database, update-cluster, and delete-database. The scope (dedicated cluster within an org) is explicit.

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?

It routes the agent precisely: call list-cluster-sizes first, verify-cluster-s3-access before supplying s3Storage, get-cluster to track async progress, and list-clusters to reconcile after an ambiguous response. When-to-use and prerequisite ordering are spelled out rather than inferred.

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

Create Cluster

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools