Skip to main content
Glama

NEXUS AI

by io.github.nexusrun
OverviewDiscussions(2)Admin

Create Managed Database

nexusai_managed_db_create

Create a standalone database, independent of any deployment, then attach it to apps. Use provider NEXUS_DOCKER for a database on NEXUS AI itself (Postgres or Redis, optional custom databaseName/username), or a cloud provider for a managed cloud instance. Paid plans only. Credentials are generated server-side and never returned through MCP. View them in the authenticated NEXUS AI dashboard. Provisioning is async; poll status until AVAILABLE before attaching.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesSlug, 3-63 lowercase chars/digits/hyphens.
engineYesREDIS is NEXUS_DOCKER only; MYSQL is cloud only.
regionNoCloud only. Defaults to the org default region.
providerNoNEXUS_DOCKER = runs on NEXUS AI (local, attachable to LOCAL_DOCKER apps on the primary host). Default AWS_RDS. GCP uses the org's Cloud Run credentials; AZURE is always private (VNet).
usernameNoNEXUS_DOCKER only. Postgres owner (default nexusadmin) or optional Redis ACL username.
allocatedGbNoCloud only. Storage in GB (20-1000, default 20).
displayNameNo
networkModeNoAWS only. "vpc" = private RDS reachable only from the App Runner VPC connector; "public" (default) = public endpoint + CIDR allowlist. Not applicable to NEXUS_DOCKER.
databaseNameNoNEXUS_DOCKER Postgres only. Initial database name (default appdb); lowercase letters, digits, underscores.
engineVersionNoCloud: required, e.g. "17.10" (postgres) / "8.0.46" (mysql) for AWS; "16"/"8.0" for GCP. NEXUS_DOCKER: optional, one of 17/16/15 (postgres) or 7 (redis), newest by default.
instanceClassNoCloud only. AWS e.g. db.t3.micro; GCP e.g. db-custom-1-3840.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / password
      Removed value: -{
-  "description": "NEXUS_DOCKER only. 12-128 chars, no whitespace/quotes/backslashes. Generated and returned once if omitted.",
-  "type": "string"
-}
    • changedInput schema / properties / username / description
      Previous value: -"NEXUS_DOCKER only. Postgres owner (default nexusadmin) or Redis ACL user (default: no ACL user, password only)."New value: +"NEXUS_DOCKER only. Postgres owner (default nexusadmin) or optional Redis ACL username."
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already mark this as a non-read-only, open-world, non-destructive mutation, but the description adds substantive traits the annotations cannot convey: paid-plan requirement, credentials generated server-side and never returned via MCP (view in dashboard), and async provisioning requiring status polling until AVAILABLE. These are genuinely useful operational disclosures.

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-loads purpose before provider guidance, then warnings (paid plans, credentials), then the async workflow. Every sentence carries distinct information, though the provider sentence is dense and slightly crowded with parenthetical detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation with no output schema, the description covers the key operational facts: credential non-return, async provisioning, and status-gated attachment. It does not state what the create call itself returns (e.g., identifier/status fields), which the absent output schema leaves as a minor gap.

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 91%, so the schema already documents parameter meaning, enums, defaults, and provider/engine constraints in depth. The description only lightly reinforces provider choice (NEXUS_DOCKER vs cloud) and adds nothing parameter-specific beyond what the schema provides; baseline 3 applies.

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 standalone database') and immediately distinguishes it from deployment-attached databases and from the sibling attach/list tools ('independent of any deployment, then attach it to apps'). An agent can identify the operation 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear selection context: use NEXUS_DOCKER for a DB on NEXUS AI (Postgres/Redis) or a cloud provider for a managed cloud instance, plus the 'Paid plans only' prerequisite. It does not explicitly exclude or contrast against siblings like nexusai_deploy_create or nexusai_managed_db_attach, so it stops short of full when/when-not guidance.

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

All NEXUS AI toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources