Skip to main content
Glama

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: install_template.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gvcNoGVC 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.
orgNoOrganization slug.
nameYesName for this database. Its workload and its credentials secret are named after it.
tierNostarter (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.
engineYesDatabase engine.
versionNoTemplate version (e.g. "3.0.1"). Omit to use the latest. See get_template for available versions.
locationNoOnly to create a GVC: An enabled location of the org, from the list a placement question gives.
storageGiBNoInitial storage in GiB (default and minimum 10). Redis keeps data in memory unless this is passed.
allowWorkloadsNoWorkloads 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

TableJSON Schema
NameRequiredDescriptionDefault
okYes
dataNoThe full result. Read this, not only the summary.
detailsNo
summaryYes
nextStepsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=true, and readOnlyHint=false, but the description adds real context beyond them: the 40-second readiness wait, generated credentials that never pass through the chat, secret-reference outputs, and the crucial warning that allowWorkloads re-applies the template, may redeploy, and resets out-of-band changes like volume snapshot settings. This genuinely enriches the safety picture, though return/auth details remain thin.

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?

It is long, but front-loaded with the core action and credentials, and nearly every clause carries a distinct fact (engine list, wait, gvc default, idempotency, destructive caveat, sibling pointer). Some sentences are dense, but nothing is mere filler.

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 9-parameter, mutating, template-driven tool, the description covers defaults, the gvc fallback path, idempotent re-call behavior, the destructive allowWorkloads caveat, and sibling routing. With an output schema present, it correctly does not need to own return-format documentation.

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 every parameter is already documented in the schema, and the description largely restates engine/credential/return behavior rather than adding parameter syntax. Baseline 3 is appropriate when the schema carries parameter semantics.

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 names a concrete verb and resource ('Install PostgreSQL, MySQL, MariaDB, MongoDB, or Redis from the Template Catalog in one call') and explicitly distinguishes itself from the nearest sibling ('Other templates: install_template'). An agent can tell what it does and what it is not without opening the 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?

It states when to use it, names the alternative for other templates (install_template), explains the gvc-omitted path (use the job GVC, ask, or create one), and clarifies re-invocation semantics ('Safe to call again...reuses what exists'). The condition for reaching for a different template is spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.