Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

data_update_where

Set columns on EVERY row matching a filter, server-side, without pulling ids into your context — e.g. derive a tier from several columns. filter/filters = the data_rows grammar; set = {column: value}. only_if_empty=true skips rows where the column already holds a value (@empty counts as empty), so ordered rules (Hot, then Tier 1, 2, 3) run first-match-wins. Start with dry_run=true: it returns matched and sample rows (from → to). Each row goes through the same checks as data_write(id=…) and lands in its data_row_history; a row changed since selection is skipped (conflicts), never overwritten. A missing target column is declared first. Returns counts, not rows. If next_cursor is set, the time budget ran out: call again with cursor=<next_cursor>. set={"journal[+]": "…"} appends a line to each row's text cell (or an element to a list), under the row lock, without a revision check: concurrent appends all land. An append is never unchanged — rerunning the rule appends again. Past 64 000 characters a cell refuses the append: a log that long belongs in a table, one row per entry.

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>",
      "set": "<set>"
    },
    "name": "data_update_where"
  }
}

Input Schema

NameRequiredDescriptionDefault
setYesThe columns to set on every matching row: `{"tier": "Tier 1"}`. A value may carry its layers (`{"valeur": "Tier 1", "comment": "rule: fit>=8"}`). A column the schema does not declare yet is DECLARED first (type inferred). A value that would ERASE (null, "", [], `@empty`) is refused. `{"journal[+]": "…"}` APPENDS a line to a declared `text` column (or an element to a `list` one) on every matching row, without reading it.
_orgNo
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
cursorNoThe `next_cursor` of a previous call that ran out of time — resumes after it.
filterNoSame grammar as `data_rows`: `{col: value}` or `{col: {op: value}}`.
_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.
dry_runNoWrite nothing: return `matched` and a few `sample` rows with from → to.
filtersNoSame grammar as `data_rows`: `[{field, op, value}]`, AND-ed with `filter`. Neither = EVERY row of the table.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
datastoreYes
only_if_emptyNoOnly rows where every `set` column is empty — the `data_rows` `empty` predicate: absent, null, "" or `@empty`. Run ordered rules with it: first match wins.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/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: conflicts are skipped and never overwritten, changed rows are revision-checked, appends run under row lock with no revision check, appended rows are never 'unchanged' and re-running appends again, missing columns are declared first, and returns are counts not rows.

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 and the dry-run-first advice, and nearly every sentence adds operational detail (conflicts, cursor, append limit). It is a dense wall of text without paragraph breaks, which costs a point on structure, but little is redundant.

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 an 11-parameter bulk mutation tool with nested objects and no output schema, the description covers write semantics, dry-run preview shape (matched, sample rows from → to), conflict counts, history side effects, and pagination via next_cursor. Nothing essential for a correct call 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?

Schema coverage is already high (82%), so the baseline is met by the schema; the description still adds real meaning — filter/filters share the data_rows grammar and are AND-ed, only_if_empty counts @empty as empty, and set supports the `{col[+]: value}` append form that the schema only gestures at.

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+resource+scope: 'Set columns on EVERY row matching a filter, server-side, without pulling ids into your context'. It also implicitly differentiates from the per-row sibling by noting 'the same checks as data_write(id=…)' and from data_rows by needing no id fetch.

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?

Gives concrete procedural guidance: start with dry_run=true, resume with cursor=<next_cursor> when next_cursor is returned, use only_if_empty for ordered first-match-wins rules, and use a table instead of appends past 64k chars. It never states explicitly when to prefer per-row data_write instead of this tool, which keeps it below a 5.

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

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