Tulina

data_drop_column

DESTRUCTIVE — erase a column from EVERY row of a datastore (confirm=True required). Removing a field from the schema takes it out of the view, but the key stays in each row: it still shows up on read, and keeps attracting writes. Writing null does not erase it either. Use it after RENAMING fields — the old names often describe the content better than the new ones, so an agent re-reading a row writes into them believing it aims right; purge them once instead of warning every agent forever. A key still DECLARED in the schema is refused: take it out of the schema first (data_set_schema). Returns {rows} = how many rows carried it, ALWAYS >= 1: a name that no row carries is REFUSED, never reported as a zero — so a success is always a removal you can tick off. The refusal says which of the two it is: a typo (no column of that name), or an ANNOTATION such as site_web.comment — served flat next to its column but stored under it, so a column purge does not reach it (write {"site_web": {"comment": null}} instead).

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>",
      "key": "<key>"
    },
    "name": "data_drop_column"
  }
}

Input Schema

Name	Required	Description
`key`	Yes	The column to erase. A key still DECLARED in the schema is refused — take it out with `data_set_schema` first. An ANNOTATION (`site_web.comment`) is not a column: erase it by writing `{"site_web": {"comment": null}}`.
`_org`	No
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`_run_id`	No	OBLIGATOIRE à 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.
`confirm`	No	REQUIRED `true` — the purge is refused without it. It erases the key from EVERY row, not just from the schema view.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`datastore`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/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 flags DESTRUCTIVE up front, requires `confirm=True`, explains that null-writing does not clear a key, and documents the return contract (`{rows}`, ALWAYS >= 1, never a zero). It even enumerates the two refusal modes and what each message means, which is behavior no schema field could convey.

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-loads 'DESTRUCTIVE' and keeps every sentence substantive, but it is long and repeats the schema-declared-key and annotation-refusal rules verbatim from the `key` schema description, which is redundant for an agent reading both. Tightening that overlap would improve it.

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 explain returns — and it does, defining `{rows}` as the count of rows that carried the key with a guaranteed lower bound of 1. Combined with destructiveness, preconditions, and failure semantics, nothing an agent needs to call this 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?

Adds real meaning beyond the 71%-covered schema for the two required parameters — `confirm` is a hard gate, and `key` must not be schema-declared and cannot address an annotation. The `_org`/`_group`/`_project`/`_run_id` plumbing parameters get no treatment in the description, though the schema documents them, so this is short of 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?

States a specific verb and resource (erase a column) plus exact scope (EVERY row of a datastore), and distinguishes it from schema-level removal ('Removing a field from the schema takes it out of the view, but the key stays in each row') and from null-writing. An agent can separate it from siblings like data_set_schema or data_update_where without opening a 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?

Gives an explicit when-to-use ('Use it after RENAMING fields') with the reason, an explicit precondition failure path ('A key still DECLARED in the schema is refused: take it out of the schema first (`data_set_schema`)'), and names the alternative for annotations (write `{"site_web": {"comment": null}}` instead). No routing decision is left to inference.

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

All Tulina 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?