Skip to main content
Glama

fline

by sh.fline
OverviewDiscussionsAdmin

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 Services 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

TableJSON 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 only state the generic mutation profile (readOnlyHint=false, destructiveHint=false), while the description adds real behavior: no password/key is ever returned by any tool, secrets surface on the dashboard Services/Storage pages, the service starts as `provisioning` and becomes `active`, and engine/version/size_class default to platform choices. This goes well beyond what the annotations disclose and contradicts nothing.

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?

Front-loads the create action and engine enumeration, which is good, but it is a single dense paragraph with digressions (the Redis-fork licensing aside, repeated 'what to ask for wherever a project wants' phrasing) that could be tightened. Most content is purposeful, but it is longer 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?

For a no-output-schema, mutation tool with five parameters, it covers creation semantics, defaults, lifecycle states, secret handling and the project-vs-workspace distinction thoroughly. The main omission is any mention of idempotency_key behavior, which matters because the annotation declares the call non-idempotent.

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 0%, so the description carries the full burden. It explains engine values, the version default and the size_class default, which covers three of five parameters, but says nothing about `name` semantics or the `idempotency_key` parameter (notable given idempotentHint=false). Partial compensation only.

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?

Opens with a specific verb+resource ('Create a data service for this workspace') and enumerates the three engine choices with plain-language meaning for each, so an agent knows exactly what it produces and which flavor to pick. It is cleanly distinguishable from siblings like get_service, list_services and delete_service.

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?

Gives explicit when-to-use (postgres/valkey/s3 selection rationale), explicit when-not-to-use ('NEVER write a postgres, redis, valkey, minio or s3 service into a compose file or a plan'), and names the alternative path (a plan variable marked scope 'managed' is wired at deploy time). It also points to the add_a_database prompt and clarifies the bucket exception.

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

All fline toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources