Tulina

data_row_history

Read the revision history of ONE datastore row: every write, newest first, with the values before and after (diff: {column: {avant, apres}}), who wrote it (acteur), under which run (run_id), through which face (source: import, agent, console, api, upload, system) and in which gesture (geste_id). champ keeps only the revisions touching that column. Page with limit and before_id (= the previous next_before_id). ⚠️ Coverage: the journal only holds writes made since it went live on 2026-09-24. A row with NO revision is NOT a row that was never modified: it may simply not have been written since. coverage.insert_recorded: false means the row predates the journal and its history starts mid-life. Deleting a row IS a revision (suppression: true, every value under avant, stamped with who deleted it). A deleted row keeps its history, readable only by whoever governs the table (row_deleted: true, deletion = who and when, null if it was deleted before the journal recorded deletions).

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>",
      "row_id": "<row_id>"
    },
    "name": "data_row_history"
  }
}

Input Schema

Name	Required	Description
`_org`	No
`champ`	No	Ne garder que les révisions qui touchent cette colonne, et ne rendre que sa partie du diff.
`limit`	No	Révisions par page, la plus récente d'abord (200 au plus).
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`row_id`	Yes
`_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.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`before_id`	No	Lire la page suivante : l'`next_before_id` de la réponse précédente. Omis = à partir de la révision la plus récente.
`datastore`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does it well: journal start date (2026-09-24), the `coverage.insert_recorded: false` caveat, deletions modeled as revisions with `suppression: true`, and restricted readability of deleted rows for non-governors. Missing only operational details like error behavior or result-size limits.

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?

Dense but front-loaded: purpose first, then return shape, then pagination, then the coverage caveats ranked after the essentials. A single long block rather than separated segments, but nearly every sentence carries distinct information.

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 9-parameter read tool with no annotations and no output schema, the description supplies return field names, pagination protocol, and the asymmetries that would otherwise cause misreading of empty results. Nothing an agent needs to call and interpret it is missing.

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 67% and the schema already documents `champ`, `limit` and `before_id`, which the description largely restates; the added nuance is that `before_id` comes from the previous `next_before_id`. The infrastructure params (`_org`, `_group`, `_project`, `_run_id`) are left entirely to the schema, so the description adds little net meaning.

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?

Opens with a specific verb+resource+scope: 'Read the revision history of ONE datastore row', then enumerates exactly what each revision carries (diff avant/apres, acteur, run_id, source, geste_id). This is clearly distinguishable from data_rows (current values) or data_row_comments (discussion), even though it does not name a sibling.

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 clear operative context: filter with `champ`, page with `limit`/`before_id`, and a strong interpretive rule that an absent revision does not mean an unmodified row. It stops short of explicitly routing the agent away from alternatives (e.g. 'for current values use data_rows'), so no explicit when-not guidance.

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?