Skip to main content
Glama
This connector has been deprecated

Duplicate listing of the same server under an old namespace. The maintained listing is Layero (ru.layero/layero): same endpoint https://mcp.layero.ru/mcp, current description and tools. The landing-page generator described here was removed in MCP 2.0.

Data API базы: бакеты файлов

data_api_buckets

Storage buckets of a database: list and create — without a secret key.

Files must be enabled for the database. A private bucket opens nothing by
itself: reading and uploading are decided by storage policies (the
dashboard → Files → Policies, or SQL on storage.objects). Creating needs
the person's consent. Needs a token with the admin scope — the storage key
is issued only to it, even for listing.

Input Schema

NameRequiredDescriptionDefault
nameNoFor create: bucket name, e.g. `screenshots`.
actionNo`list` — the database's storage buckets; `create` — a new bucket.list
publicNoFor create: anyone with the link can download files. Default false — who reads and uploads is decided by storage policies.
databaseNoThe database: name, slug or id. Without it — the organization's only database with the Data API enabled.
confirmedNotrue — the person has already agreed in the chat after seeing what will change. A client with forms does not need it: the server asks the person itself. Never set it without the person's explicit consent.
organizationNoOrganization slug. Without it — the only one, or the personal one.
max_size_bytesNoFor create: file size limit in bytes.
allowed_mime_typesNoFor create: allowed MIME types, e.g. ["image/jpeg", "image/png"].

Output Schema

NameRequiredDescriptionDefault
actionYes
bucketsNo
changedNo
databaseYes
next_actionYes
organizationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the annotations (openWorldHint, destructiveHint=false) the description discloses that a private bucket grants no access by itself, that reads/uploads are governed by storage policies, that creation requires the person's consent, and that the storage key is only issued to an admin-scope token even for listing. These are non-obvious authorization and side-effect facts an agent could not infer from annotations or schema; nothing contradicts destructiveHint=false.

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?

Four short sentences, front-loaded with the resource and operations before the access constraints. The line-broken formatting and the cryptic 'without a secret key' clause cost it a little, but nothing is wasted.

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?

With an output schema present, return values need not be explained, and the description covers the main risks: enablement, policies, consent, and token scope. It does not mention behavior when `database` is omitted and ambiguous, though the schema covers that default.

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 already carries a description; the prose adds only the general point that creating needs consent, which the schema's `confirmed` field also covers. Baseline 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific resource (storage buckets of a database) and both operations (list and create), which clearly separates it from sibling tools like data_api_keys or data_api_auth. The trailing phrase 'without a secret key' is a little cryptic but does not obscure the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description supplies real prerequisites (Files must be enabled, admin-scope token required even for listing, consent needed for create), which tells the agent when the call will work. It never names an alternative tool or states when NOT to use this one, so routing guidance relative to the data_api_* siblings is implied rather than explicit.

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.

Resources