Skip to main content
Glama

Create a data service

create_service

Create a data service for this workspace: engine=postgres for a PostgreSQL database, engine=valkey for a Valkey instance — the BSD-licensed fork of Redis, which every Redis client speaks unchanged, so ask for it wherever a project wants Redis — or engine=s3 for object storage, an S3-compatible bucket with a size limit, which is what to ask for wherever a project wants a bucket, file uploads or blob storage. It belongs to the workspace and not to a project: it outlives any project and can be read by several. NEVER write a postgres, redis, valkey, minio or s3 service into a compose file or a plan. A project does NOT need this tool to get a database: a variable the plan marks scope "managed" with ref "postgres" or "valkey" is wired at deploy time to a workspace service named -postgres (or -valkey), reused or created, with its connection string written in by the platform. A service created here under any other name is ignored by that path, so creating one for a project first ends with two. See the add_a_database prompt. A bucket is never wired that way: create it here, and the person pastes its values into whichever variables their application reads. This tool does NOT return a password or key and no tool does: the connection string is shown to the person on the Databases page of their fline dashboard, and a bucket's endpoint, key and bucket name on its Storage page. Do not ask the user for a host, port, password or access key. engine and version default to what the platform serves and size_class to the smallest; the answer names the service as provisioning, which becomes active once it has been verified end to end.

Input Schema

NameRequiredDescriptionDefault
nameYes
engineNo
versionNo
size_classNo
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations declare the write/non-idempotent profile, and the description adds substantial behavior the annotations cannot: no password or key is returned by any tool, where the connection string is surfaced, the provisioning→active status lifecycle, and the engine/version/size_class defaults. This is genuinely additive rather than restating annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is correctly front-loaded, but the first sentence is a run-on packing three engine definitions into nested dashes, and the body is a dense wall of caveats. Each claim is useful, yet the formatting makes it harder to scan than it needs to be.

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?

Given no output schema and 0% param coverage, the description does heavy lifting: it states defaults, the returned status, where secrets live, and the workspace-vs-project ownership rule. The only real gap is any mention of the idempotency_key semantics.

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?

With 0% schema coverage and 5 parameters, the description must carry the full burden. It explains engine values and the defaults for version and size_class, but the required `name` parameter's acceptable values/format is only implied through the <project name>-postgres discussion, and `idempotency_key` is never mentioned at all.

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 opening sentence gives a precise verb+resource ("Create a data service for this workspace") and immediately enumerates the three valid engine values with a plain-language gloss for each. An agent knows exactly what the tool produces and which inputs map to which backend 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?

Explicit when-not guidance is provided: NEVER write postgres/redis/valkey/minio/s3 into a compose file or plan, a project does NOT need this tool to get a database via the managed-ref path, and buckets are the exception that must be created here. It even points to the add_a_database prompt as the alternative workflow.

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.