Skip to main content
Glama
Sign In

Supero

by io.github.supero-platform
OverviewDiscussions(2)Admin

build_bind_data_source

Destructive

Bind source streams to the app's schemas. mode='live_read' (default: read-only BYODB / warehouse), 'live_readwrite' (BYODB read+write, DOMAIN-ADMIN only), or 'sync' (copy into SuperoDB). Modes by source: postgresql, supabase, mysql take all three; mssql takes sync and live_read; oracle and mongodb take sync only; a REST api takes sync and live_read; warehouses take live_read only. For live modes, discovery must have run and each binding's source must match a discovered stream; the bind VERIFIES the live mapping materialized. A NEW live table must state tenant_binding: ask the data owner which rows belong to which tenant, never assume. Bound live schemas are read/written via ORDINARY app CRUD, nothing goes in the bundle.

Input Schema

NameRequiredDescriptionDefault
bindingsYesOne entry per app schema to back with a source stream.
connector_idYesThe connector to bind (from build_connect_data_source).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / bindings / items / properties / confirm_tenant_binding_downgrade
      Added value: +{
+  "description": "Set true, separately from tenant_binding, only when the data owner has agreed to move this table from mode 'column' to 'fixed', which removes its row filter. Required for that move when the gate enforces.",
+  "type": "boolean"
+}
    • changedInput schema / properties / bindings / items / properties / mode / description
      Previous value: -"live_read (default, read-only), live_readwrite (domain-admin key only), or sync (copy into SuperoDB)."New value: +"live_read (default, read-only), live_readwrite (domain-admin key only; postgresql, supabase and mysql only), or sync (copy into SuperoDB). oracle and mongodb are sync only."
    • changedInput schema / properties / bindings / items / properties / tenant_binding / description
      Previous value: -"How live rows map to Supero tenants. OMIT for the default {mode:'fixed', tenant:'default-tenant'} (all rows visible to the default tenant/admin — required, else live reads 403 tenant_binding_missing). For per-tenant isolation pass {mode:'column', tenant_field:'<col>', tenant_value_map:{<supero_tenant>:<source_value>}}."New value: +"How live rows map to Supero tenants. State this for every new live table: ask the data owner which of these applies, never assume. (1) Rows of several tenants, separated by a column: {mode:'column', tenant_field:'<source column>', tenant_value_map:{'<supero tenant>':'<value in that column>'}, on_unmapped_tenant:'deny'}; each caller reads only its mapped rows, and a tenant not in the map is refused, default-tenant included. (2) The whole source belongs to one named tenant: {mode:'fixed', tenant:'<that tenant>'}; only that tenant's callers can read. (3) Admin or internal data only: {mode:'fixed', tenant:'default-tenant'}; default-tenant callers read every row with no filter, and every named-tenant caller gets 403 tenant_mismatch. Last resort, only if a fixed bind is refused because a column looks like a tenant discriminator and the owner has told you that column does not separate tenants: add single_tenant_source_confirmed:true. It turns off row filtering for that source and needs the owner's answer; your API key and the time are recorded as the attestation."
  2. Changed3 schema fields changed
    • addedInput schema / properties / bindings / description
      Added value: +"One entry per app schema to back with a source stream."
    • addedInput schema / properties / bindings / items / properties / mode / description
      Added value: +"live_read (default, read-only), live_readwrite (domain-admin key only), or sync (copy into SuperoDB)."
    • addedInput schema / properties / connector_id / description
      Added value: +"The connector to bind (from build_connect_data_source)."
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and openWorldHint=true, but the description goes beyond them: it explains that the bind verifies the live mapping materialized, that bound schemas use ordinary app CRUD, that unmapped tenants get refused/403, and that the downgrade gate records an attestation. It never explicitly warns what is destroyed by a rebind, which is the one annotation-relevant gap.

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-loaded with the core action, then constraints, then the safety-critical tenant warning. The mode-by-source sentence is dense but every clause carries routing information; only minor redundancy with the schema's enum descriptions prevents a 5.

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 destructive, open-world bind operation with only two top-level params and no output schema, the description supplies the mode matrix, preconditions, tenant-binding decision procedure, and downgrade gate. Nothing an agent needs to invoke it safely is missing.

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?

With 100% schema coverage the baseline is 3, but the description adds the source-type-to-mode compatibility matrix and the requirement that `source` match a discovered stream, which are not fully captured in the schema. The tenant_binding guidance is largely duplicated from the schema, keeping it below a 5.

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 specific verb and resource ('Bind source streams to the app's schemas') and the rest immediately scopes it by mode and source type. An agent can distinguish this from build_connect_data_source and build_discover_source 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?

It states exactly which modes apply per source (postgresql/supabase/mysql all three, oracle/mongodb sync only, warehouses live only, etc.) and the precondition that discovery must have run for live modes. Explicit when-to-use and when-not-to-use guidance is present.

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

All Supero 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