Skip to main content
Glama
Sign In
RawTree MCP Server

RawTree MCP Server

Official
by rawtreedb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create API Key

create-api-key

Purpose: Create a new RawTree API key for a cluster.

Instructions

Purpose: Create a new RawTree API key for a cluster.

NOT for: User login. Use RawTree auth/CLI or the dashboard for that workflow.

Returns: The new API key value and expires_at (UTC timestamp or null for never). The API key is only shown once, so you MUST display it to the user.

Auth: Uses POST /v1/keys and requires admin permission for database API key auth.

When to use:

  • User needs a key for CI, an agent, a connector, or a script

  • User wants a read-only, write-only, read-write, or admin credential

  • User asks to rotate credentials by creating a replacement before revoking the old key

Input Schema

NameRequiredDescriptionDefault
nameYesHuman-readable API key name.
clusterNoRawTree cluster to use for this operation.
databaseNoOptional default database for the new key. RawTree uses the default database when omitted.
expires_atNoOptional expiration as a future RFC 3339 timestamp with a timezone. The API validates and normalizes it to UTC. Omit or use null to never expire. Expiration cannot be updated; create a replacement key to change it.
permissionNoPermission level. Prefer read_only for query-only agents and write_only for ingest-only connectors.read_write
organizationNoRawTree organization containing the target cluster.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.2
    • addedInput schema / properties / expires_at
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Optional expiration as a future RFC 3339 timestamp with a timezone. The API validates and normalizes it to UTC. Omit or use null to never expire. Expiration cannot be updated; create a replacement key to change it."
+}
  2. 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 default database for the new key. 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"
+}
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does: it discloses the one-time visibility of the key value, the returns shape (key value + expires_at, null meaning never), the auth requirement (POST /v1/keys, admin permission), and the immutability of expiration. These are exactly the non-obvious traits an agent needs before invoking.

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?

Front-loaded purpose, then exclusions, returns, auth, and use cases — every block earns its place. The heavy markdown sectioning is slightly more scaffolding than the content requires, keeping it off a 5.

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 contract itself (key value shown once, expires_at semantics), plus auth and failure-relevant constraints. Enough for an agent to call and then handle the result 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 all six parameters are already documented; the description only nudges on the permission enum ('prefer read_only for query-only agents'). That is additive but thin, so the baseline 3 is right.

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 and resource ('Create a new RawTree API key for a cluster') and scopes it to a cluster. The 'NOT for: User login' line plus sibling names (list-api-keys, delete-api-key) make it trivially distinguishable from adjacent tools.

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 exclusion ('NOT for user login — use RawTree auth/CLI or the dashboard') and three concrete when-to-use scenarios (CI/agents/scripts, permission tier selection, rotation-before-revoke). Nothing about the decision is left to inference.

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