Skip to main content
Glama

data_get_schema

Read a datastore's declared TYPED schema (the one data_set_schema posts). Returns {datastore, ns_id, schema, enforced, reglages} — schema is null when none is declared, which is a normal state, not an error. reglages gives the head setting AS APPLIED, default included: new_rows (create | reject — whether a write that designates no existing row may create one). unknown_columns was REMOVED on 2026-10-05 (columns and values are always checked); a stored leftover of it, or of strict, unknown_fields and key_required, is named in warning. ns_id is the table's NUMBER (e.g. 174) and datastore its canonical name, whatever form you addressed it by: pass the NUMBER as datastore from here on — a name still resolves until 2026-11-08, then it is refused. Read it BEFORE amending: data_set_schema posts the schema WHOLE, it does not merge, so adding one field means re-posting the existing definition plus that field. The work queue itself needs NOTHING declared: data_claim_next reserves rows on any table, with or without a schema. A lifecycle block only RESTRICTS it, on the column that carries the block: states/transitions/terminal — transitions maps each state to a LIST of reachable states, even for one ({"a": ["b"]}, never {"a": "b"}, which is refused) — plus max_claims + abandon_state — the ceiling of claims WITHOUT a write past which a row leaves the queue; labels ({state: "Displayed name"}) names each step for a screen and is never applied to a write. enforced lists the validation keys THIS deployment actually applies (required, max_length, pattern…): check what you are about to declare against it, rather than against documentation — a key posted but not enforced looks like a contract and is not one, and one enforced only after the next deploy freezes rows all at once, weeks after the cause. ⚠️ It says what BITES, not what is USEFUL: a key absent from enforced is not dead — presentation keys are read by whoever renders the table, and oto cannot know who reads what downstream. Never drop a key on the strength of its absence here. warning appears only when the stored schema still carries keys no level admits — posted before the vocabulary was closed (2026-10-01), typically a leftover enum beside the options that actually constrains the field. When it does, trust the key the warning names: the other is a residue, whatever it says. Writing a NEW unknown key, or changing one, is refused. tel_que says which reading this is. servi (default) is the schema as served to you: through this tool, columns the owner keeps from agents are left out, and colonnes_masquees counts them. stocke — owner or governor only — is the schema as stored, whole, plus gardes: per column, what the guards actually do HERE (verrouillees, masquees_a_l_agent, lecture_seule_agent) and sans_effet, what is declared and applied by nothing, with the reason. forme=compacte keeps only the keys that constrain, without prose or null keys — for inspection, never to post back.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "datastore": "<datastore>"
    },
    "name": "data_get_schema"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNo
formeNo`complete` (default): the schema as served, every key. `compacte`: only the keys that constrain — structure and validation (`type`, `options`, `required`, `lifecycle`…) — without `description`, `label`, `meta` or null keys. To INSPECT a schema only: NEVER post a compact schema back, `data_set_schema` would erase every description and label of the table.complete
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
tel_queNo`servi` (default): the schema as served to YOU — through this tool, columns the owner keeps from agents (`agent_access: "none"`) are left out. `stocke`: the schema as STORED, whole, with `gardes` — what each column guard actually does on this table. Reserved to whoever owns or governs the table (403 otherwise).servi
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
datastoreYes

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it states that a null `schema` is a normal state and not an error, enumerates the return keys, documents which legacy keys were removed and how they surface in `warning`, explains that `enforced` reflects this deployment rather than documentation, and discloses the 403 restriction on `stocke` plus the date-bound migration from name to numeric id. These are exactly the behavioral traits an agent could not infer from the schema.

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?

Purpose and return shape are correctly front-loaded, but the remainder is a single dense block mixing return documentation, deprecation history, lifecycle vocabulary rules and parameter caveats with no paragraph or list structure. Substantial space goes to explaining the schema language (`transitions` must be lists, `max_claims`/`abandon_state`, `labels`) rather than the act of reading, which makes the call-relevant content harder to extract than it needs to be.

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?

There is no output schema, so the description must describe the return value — and it does, naming all five top-level keys, the conditional `warning` and `colonnes_masquees`, and the `gardes`/`sans_effet` blocks in the stored mode. Combined with the migration deadline and the mandatory read-before-write rule, an agent has everything needed to call this correctly and interpret the result.

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

Parameters5/5

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

Schema coverage is only 71%, and critically the required `datastore` parameter has no schema description at all — the description compensates by explaining that it returns the table's NUMBER and canonical name and that the NUMBER must be used from here on, with names refused after 2026-11-08. It also adds operational meaning to `forme` (compact schemas must never be posted back) and `tel_que` (served vs stored, with the authorization gate) beyond the enum values themselves.

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 opening clause gives a specific verb and resource — 'Read a datastore's declared TYPED schema' — and immediately anchors it to the sibling that writes it ('the one `data_set_schema` posts'), so the agent knows this is the read side of that pair. It does not distinguish itself from `data_patch_schema`, another nearby schema tool, so the differentiation is good but not exhaustive.

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 an explicit sequencing rule — 'Read it BEFORE amending: `data_set_schema` posts the schema WHOLE, it does not merge' — which tells the agent exactly when this call is mandatory. It also constrains `forme=compacte` to inspection only ('NEVER post a compact schema back') and warns that `tel_que=stocke` is owner/governor only (403 otherwise). What is missing is any statement of when this tool should NOT be used (e.g. when `data_list_datastores` or `data_patch_schema` suffices).

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