Control Plane

Add a Database

add_database

DestructiveIdempotent

Install PostgreSQL, MySQL, MariaDB, MongoDB, or Redis from the Template Catalog in one call, with credentials Control Plane generates so no value passes through this chat. Lets the listed workloads connect, waits up to 40 seconds for the database to be ready, and returns its internal host and port plus the env values an app uses, as cpln://secret references. Without gvc it uses the GVC a job made for apps, asks about any other, or creates the first one once the user picks a location. Safe to call again with the same arguments: it reuses what exists and reports readiness. On an existing database, allowWorkloads replaces its access rules by reapplying its template, which can redeploy it and resets changes made outside its values, such as volume snapshot settings. Other templates, or a setting this tool does not take such as backups: browse_templates with the template name, then install_template.

Input Schema

Name	Required	Description
`gvc`	No	GVC the database runs in; its locations are where it runs. Omit it to use the GVC a job made for apps, or to create the first one. A name that does not exist yet creates that GVC in location.
`org`	No	Organization slug.
`name`	Yes	Name for this database. Its workload and its credentials secret are named after it.
`tier`	No	starter (default): one instance; Redis keeps the one Sentinel it needs to start. ha: failover, when the user wants it: Redis only (3 Redis and 3 Sentinel). PostgreSQL and MongoDB failover are separate templates (postgres-highly-available, mongodb-cluster) through install_template.
`engine`	Yes	Database engine.
`version`	No	Template version (e.g. "3.0.1"). Omit to use the latest. browse_templates with `name` lists the versions.
`location`	No	Only to create a GVC: An enabled location of the org, from the list a placement question gives.
`storageGiB`	No	Initial storage in GiB (default and minimum 10). Redis keeps data in memory unless this is passed.
`allowWorkloads`	No	Workloads that may connect. Omit to allow every workload in the same GVC, including ones created later; an app in another GVC must be listed. A listed workload that does not exist yet is admitted only once the database is updated after it exists: allow_workload_access on the database then.

Output Schema

Name	Required	Description
`ok`	Yes
`data`	No	The full result. Read this, not only the summary.
`details`	No
`summary`	Yes
`nextSteps`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

changedInput schema / properties / version / description

Previous value: -"Template version (e.g. \"3.0.1\"). Omit to use the latest. See get_template for available versions."New value: +"Template version (e.g. \"3.0.1\"). Omit to use the latest. browse_templates with `name` lists the versions."

AddedSep 30, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare idempotentHint=true and destructiveHint=true; the description earns credit by explaining *how* — same args reuse existing resources, and allowWorkloads re-applies the template, potentially redeploying and resetting out-of-band changes like volume snapshot settings. It also discloses the 40-second readiness wait and that credentials are generated server-side. That said, the destructive caveat is a single dense clause rather than a clearly separated warning, leaving some ambiguity about exactly which changes get reset.

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?

Purpose and defaults are front-loaded, and every sentence carries information (credentials, readiness, idempotency, destructive caveat, alternative). The middle section is very dense — several distinct behaviors packed into one long sentence — which slightly hurts scanability.

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?

Covers what annotations and schema cannot: the GVC fallback chain, the readiness wait, the returned host/port and cpln://secret env references, and the destructive re-apply behavior. For a 9-parameter creation tool with a destructive hint, this is complete.

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 coverage is 100%, so the baseline is 3. The description reinforces the gvc default behavior and the allowWorkloads admission rules, but these are largely already spelled out in the property descriptions, so it adds little beyond the schema.

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?

Names a specific action (install a database) plus the exact engine set and source (Template Catalog), and distinguishes itself from install_template/browse_templates by routing non-listed templates or unsupported settings there. An agent can tell it apart from install_template without opening either 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?

Explicitly states the fallback when gvc is omitted, what happens on re-invocation, and the exact alternative path ('browse_templates with the template name, then install_template') for other templates or settings like backups. It also flags the risky case (existing database + allowWorkloads) in advance.

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

All Control Plane tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.