Skip to main content
Glama

oto_apps

Apps: screens people build on the platform — dashboards, review queues. Before building or changing one, read the guide: oto_guide op=read slug=build-apps. An app is a manifest (the tables, fields and agents it touches) plus HTML that runs sandboxed and talks to the platform through its window bridge. Not a memory page. An app has its OWN owner and shares, like a table: a new one belongs to you, in your active organization, private unless the org shares new apps by default; share or transfer it with oto_resource (resource_type=app). Projects only FILE apps (shown on the project page), they give no access. op=list (no project: your active org's apps; project_ids: those filed there; cards, no HTML) / get (app_id; with manifest, HTML and rev) / create (title, manifest, html, optional thumbnail, optional project_id to file it) / read_file (app_id, file_id: a file a person dropped in the app, for the run they started — PDF text, a sheet as CSV, text inline, plus a signed link to the original) / put_file (app_id, name, content or content_base64, media_type: hand a RESULT file back to the app, for the person whose run this is — they get it with oto.files() / oto.download; PDF, Word, Excel, text, CSV, JSON, 20 MB) / update (app_id, any of those; pass expected_rev from get → 409 if it changed) / patch (app_id, edits: exact find → replace in the HTML, each find unique, all or nothing; returns rev, replaced and warnings, never the HTML — prefer it to update for any change smaller than the whole page) / archive / unarchive / revisions / restore (revision_id) / file / unfile (app_id, project_id) / validate (manifest, and app_id for an existing app, optional html: the problems a create would refuse, nothing written). create, update, patch, restore and validate also return warnings: oto.rows / oto.aggregate calls that sort, filter, group or measure on a field the manifest doesn't declare (_created_at / _updated_at are always sortable and filterable) — the open app would refuse them, so fix them first. Every declared table and agent must be within YOUR reach and in the app's organization: otherwise 400 invalid_manifest, each problem listed. In the HTML, window.oto: rows(table, {filter, orderBy, limit}) / aggregate(table, {groupBy, metrics, filter}) / set(table, rowId, field, value) / add(table, values) / upload(file) → {id, name, mediaType, size} (manifest files: true; PDF, Word, Excel, text, CSV, JSON; 20 MB a file, 1 GB per viewer per app, kept 30 days) / files() → each with origin upload or agent / download(fileId) (opens the viewer's own file) / runAgent(agent, {input, files: [ids]}) → {jobId} — the run gets each file's text and reads it in full with op=read_file / job(jobId) / runs(agent) / go(route). A click in the app does NOT approve anything: every set, add, upload and runAgent is shown by the HOST screen (outside the app) with what it writes, and runs only once the viewer confirms there — cancelled, it rejects. Ask for one gesture at a time, from a click. One run of an agent waits at a time (run_already_queued): collect files, then one runAgent with files: [...].

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": {
      "op": "<op>"
    },
    "name": "oto_apps"
  }
}

Input Schema

NameRequiredDescriptionDefault
opYes
_orgNo
htmlNo
nameNoput_file: the file's name, with its extension (`summary.csv`, `report.docx`).
editsNopatch: exact replacements in the app's HTML, applied in order, all or nothing — `[{"find": "…", "replace": "…"}]`; `find` must appear exactly once (or pass `"all": true`).
titleNo
app_idNo
contentNoput_file: the file's TEXT (CSV, Markdown, text, JSON). Exactly one of `content` or `content_base64`.
file_idNoread_file: a file a person dropped in the app (its id comes with the run's input).
archivedNo
manifestNo
thumbnailNo
media_typeNoput_file: its type (`text/csv`, `application/pdf`…); judged on the bytes anyway.
project_idNocreate: also file the new app in this project. file / unfile: the project. list: only the apps filed in it.
project_idsNolist: only the apps filed in these projects (at most 200). Without any project: the apps of your active organization.
revision_idNo
expected_revNo
content_base64Noput_file: the file's bytes in base64 (PDF, Word, Excel).
clear_thumbnailNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.9/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: sandboxed HTML and the window bridge, ownership/sharing defaults on create, the permission constraint that every table and agent must be in the caller's reach or 400 invalid_manifest, expected_rev producing 409, patch being all-or-nothing with find-uniqueness, and the host-side confirmation gate that makes in-app clicks non-approving. This is far beyond what structured fields 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-loaded with the guide pointer and the core concept before the op-by-op breakdown, and every sentence carries concrete information. It is nonetheless a dense wall of text with several long clauses that an agent must parse carefully; a little more line-breaking per op would improve scanability without losing content.

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 14-op mutation tool with no output schema, the description supplies return shapes (list returns cards without HTML; get returns manifest, HTML and rev; patch returns rev, replaced, warnings but never HTML), the warnings contract, and the error paths (409, 400 invalid_manifest, run_already_queued). Nothing essential to correct invocation appears missing.

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 42% across 19 parameters, but the description compensates heavily by mapping operations to their parameters (list/project_ids, get/app_id, create/title+manifest+html+thumbnail+project_id, read_file/app_id+file_id, put_file/name+content|content_base64+media_type, update/expected_rev, patch/edits, restore/revision_id, file/unfile). It also adds semantics the schema lacks, such as edit uniqueness, the 'all': true escape hatch, and what patch returns.

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 concrete definition — 'screens people build on the platform — dashboards, review queues' — and immediately contrasts it with memory pages, tables and projects. Combined with the op enum, an agent can tell exactly what resource this manipulates and how it differs from siblings like data_app or oto_resource.

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?

Explicitly routes the agent: read oto_guide op=read slug=build-apps before building, use oto_resource for sharing/transfer, prefer patch over update for sub-page changes, and use collect-then-one-runAgent because of run_already_queued. It gives both when-to-use and when-to-use-something-else with named alternatives.

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