Skip to main content
Glama

oto_import

Load a file the server can reach into a table or a project — the content never goes through the conversation. Use it instead of data_write rows for any file (CSV export, Google Sheet, Clay export, attachment). CSV: , ; or tab, UTF-8 / UTF-16 / cp1252, headers matched to column keys or labels; new headers become text columns. Pass key so a re-run updates instead of appending. A big file stops after ~40 s with resume_from: call again with it and source_sha256.

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": {
      "source": "<source>"
    },
    "name": "oto_import"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyNoColumn that DESIGNATES a row: a re-run then updates instead of appending, no `upsert` needed. Omitted, the file matches on the declared key but ADDS. Default: the table's declared key.
_orgNo
titleNo
formatNoDefault: from the file name or type.
sourceYesWhere the file is: `{kind:"url", url}` (public link; a Google Sheets share link works if the sheet is public, `gid` picks the tab), `{kind:"drive", file_id}` (your Google account; a native Sheet exports its first tab as CSV), `{kind:"project_file", project_id, file_id}`, `{kind:"gmail", message_id, filename}`, a messaging attachment's `source` as read (`{kind:"unipile", channel, url}`), a recording's `source` as read (`{kind:"transit", ref}`), or a file YOU produced: `{kind:"content", filename, base64}` (or `text` instead of `base64`), 256 KB at most. With `target="project_file"`, the file is filed in the project as is.
targetNodatastore
upsertNo`true` = MERGE when the key value already exists — for a write that ADDS (neither `id` nor `key=`), and for rows of one call that share a key value. A write that designates by `key=` needs no `upsert`. Every merge of a batch comes back in `fusions`. Without it, an adding write on an existing key, or two rows of one call on the same key, is REFUSED (`business_key_exists`). Refused on a table with no business key: there is nothing to merge on.
filenameNoproject_file only. Default: the source's file name.
datastoreNo
separatorNoCSV only. Default: detected.
project_idNo
descriptionNo
resume_fromNoFrom a previous receipt, when the file did not fit one call. Needs `source_sha256`.
source_sha256NoFrom the previous receipt: the resume is refused if the file changed.
declare_columnsNoDeclare headers that match no column as text columns (label = header); for NDJSON, keys no column declares, typed from their values. Existing columns are never changed. Off, a column the schema does not declare is refused.
origine_overrideNo`origine_override=true` states that this call sets the `origine` layer (the value at the START, at import time) knowingly. Without it, writing an origin is refused. ⚠️ Nothing captures an origin automatically any more: `origine: "system"` was REMOVED on 2026-09-08, so writing the value alone keeps nothing — an overwrite is final. For a real IMPORT, prefer `donnees_d_origine=true`, which writes both versions — the current value and the origin — in the same gesture, at the moment the value enters. This parameter only says "I know I am setting that layer", and it applies to this call only. A cell without an `origine` layer has no known starting value: the absence of the layer says so, never a text in its place.
donnees_d_origineNo`donnees_d_origine=true` sets the FIRST version of the data (the origin) and marks the write as an import in the journal: this call brings data AS THE CLIENT HANDED IT OVER. Each cell gets its `origine` version frozen at the same time as its current value, carrying the same layers: put the provenance in `<field>.comment` and it lands in both. Use it for the import itself, NOT for enrichment — what an agent establishes is the current version. An origin already set is never overwritten (a re-import updates the current version and leaves the origin alone), and an empty cell gets nothing: the client handed over nothing there, which is not the same as handing over an empty value.

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?

No annotations exist, so the description carries the full load; it discloses the server-side fetch model, supported encodings, header-mapping behavior, idempotency via `key`, and the timeout/refusal-on-big-file pattern — all real behavior beyond the call signature. It stops short of explaining the origin-layer refusal semantics and the receipt/`fusions` output shape, which are significant for a 17-parameter mutation tool.

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?

Purpose is front-loaded in the first clause, then the alternative, then format and paging specifics — a sensible information order with no filler sentences. The CSV encoding/delimiter enumeration is slightly dense but each item is actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter, nested-source, no-output-schema tool with no annotations, the description covers the mechanics of loading but not the two-mode distinction (import of origin vs current-value write) that the schema flags as consequential. An agent gets the happy path right but must read the schema to avoid the origin-layer refusal and to understand what comes back.

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 65% and the schema itself is verbose, so the schema does most of the work. The description reinforces `key`, `resume_from`/`source_sha256`, and implicitly `separator`/`declare_columns`, but adds little meaning not already stated in the parameter descriptions, and never touches `origine_override`/`donnees_d_origine`, whose distinction drives correct usage.

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 (load a file the server can reach into a table or a project) plus the defining constraint that content never passes through the conversation. It also explicitly names the sibling it replaces (`data_write` rows), so an agent can route without opening either 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 rule ('instead of data_write rows for any file') with concrete examples (CSV export, Google Sheet, Clay export, attachment). It also supplies the operational branch condition for large files: stop at ~40 s, then re-call with `resume_from` and `source_sha256`.

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