Connections

My workspace's database

connections_database

Destructive

The workspace's own Postgres database for its website or app (tables, rows, SQL), with vector, pg_trgm, pgcrypto and uuid-ossp installed. Call this when the member wants to store data for a project, create tables, save or read rows, or run a migration. Runs in the workspace this chat is pinned to. Actions: create: make the database (safe to repeat; never changes existing data). status: whether it is ready, its size and its limits. tables: every table with an estimated row count and its columns. sql: run ONE statement in sql (use $1, $2 with params for values), or several in order in statements as one transaction (all succeed or none do), as the workspace's own login; reads return up to 1000 rows and 1 MB and say truncated when cut, a statement stops after 15 seconds, and a migration batch holds at most 50 statements. It cannot reach any other database and never returns a password. Create tables with plain DDL, e.g. create table if not exists notes (id uuid primary key default gen_random_uuid(), body text). audit: the newest admin actions on this database (when it was created, frozen, thawed or erased, and each schema-changing SQL call, with who did it and when); the workspace owner only.

Input Schema

Name	Required	Description
`sql`	No	sql: one SQL statement. Use $1, $2... for values and pass them in params.
`limit`	No	audit: how many of the newest entries to return (default 50, at most 200).
`action`	Yes	What to do.
`params`	No	sql: values for $1, $2... in `sql`, sent as text; Postgres converts them to the column types.
`person`	No	Linked person to run this call as (first name). Omit to run as the connection's holder.
`dry_run`	No	Preview only.
`project`	No	Workspace to run this call in (id or name).
`statements`	No	sql: several statements run in order in one transaction (a migration). Use this or `sql`, not both.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "create",
-  "status",
-  "sql",
-  "tables"
-]New value: +[
+  "create",
+  "status",
+  "sql",
+  "tables",
+  "audit"
+]

addedInput schema / properties / limit

Added value: +{
+  "description": "audit: how many of the newest entries to return (default 50, at most 200).",
+  "type": "number"
+}

AddedNov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: create is idempotent and never mutates existing data, sql batches run as a single all-or-nothing transaction, reads cap at 1000 rows / 1 MB with a `truncated` flag, statements time out at 15 seconds, batches hold at most 50 statements, no passwords are ever returned, and audit is owner-restricted. These are exactly the operational guardrails an agent needs.

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?

The description is long but well structured: purpose first, then usage trigger, then a compact action-by-action breakdown. A few clauses are redundant with the schema (e.g. restating the $1/$2 convention), but each sentence carries real information and none are 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 five-action database tool with 8 parameters and no output schema, the description covers everything an agent needs: how to create, how to inspect, how to query, limits on results and runtime, transaction semantics, and the audit action's access restriction. No meaningful gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 100%, so the baseline is 3. The description still adds value by explaining the mutual exclusivity of `sql` vs `statements` in behavioral terms (one statement vs a transactional migration batch) and by stating the parameter placeholder convention ($1, $2 with `params`) in context. The 50-statement batch cap is also surfaced, which the schema only partially implies.

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 specific resource (the workspace's own Postgres database) and enumerates the operations available through the action enum (create, status, tables, sql, audit). It clearly distinguishes this tool from siblings like connections_storage_* or connections_execute by scoping it to a dedicated relational database with specific extensions installed.

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?

It gives explicit trigger conditions: 'Call this when the member wants to store data for a project, create tables, save or read rows, or run a migration.' It also bounds the tool with 'It cannot reach any other database,' which implies when it is not applicable. There is no explicit named alternative for those cases, keeping it out of 5 territory.

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

All Connections 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.

Resources

Need Help?