Skip to main content
Glama
Sign In
RawTree MCP Server

RawTree MCP Server

Official
by rawtreedb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List API Keys

list-api-keys

Purpose: List API keys for a RawTree cluster.

Instructions

Purpose: List API keys for a RawTree cluster.

NOT for: Creating or revoking credentials. Use create-api-key or delete-api-key for those workflows.

Returns: API key names, IDs, API key hints, permissions or database roles, default database, creation dates, and expires_at (UTC timestamp or null for never).

Auth: Uses GET /v1/keys and requires an admin database API key.

When to use:

  • User asks what API keys exist

  • You need the key ID before revoking a key

  • You need to audit permissions for a database

Input Schema

NameRequiredDescriptionDefault
clusterNoRawTree cluster to use for this operation.
organizationNoRawTree organization containing the target cluster.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 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 / organization
      Added value: +{
+  "description": "RawTree organization containing the target cluster.",
+  "minLength": 1,
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does: it discloses the auth requirement (admin database API key), the underlying endpoint (GET /v1/keys), the exact returned fields, and the null-vs-UTC semantics of expires_at. This is exactly the context an agent needs before calling a credentialed read.

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?

Header-labelled sections are front-loaded with Purpose and exclusions first, then returns/auth/usage. The returns enumeration is long but earns its place because there is no output schema.

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?

No output schema exists, yet the description enumerates return fields, and it covers auth, endpoint, and exclusions. Nothing an agent needs in order to call this correctly is missing.

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% and both parameters (cluster, organization) are documented in the schema, so the baseline is 3. The description adds no additional meaning about scoping or defaults for these parameters.

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 (list API keys for a RawTree cluster) and explicitly distinguishes itself from the sibling create-api-key and delete-api-key tools. An agent can route correctly 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?

Includes an explicit 'NOT for' block naming the alternatives, plus three concrete 'When to use' triggers (audit permissions, need key ID before revoking, inventory question). Both the positive and negative routing cases are covered.

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