Skip to main content
Glama
Sign In

Autario

by com.autario
OverviewDiscussionsAdmin

create_app

Create a data app on autario in ONE call, owned by you. You give it a name and an entry: either an https URL where the app already runs, or the app itself which autario then hosts and serves inside a locked sandbox: one HTML document (content, max 512 KB), or index.html plus the JavaScript, CSS, images, fonts and further pages it loads by relative path (files, max 50 files, 1 MB each, 2 MB in total). autario gives the app its id (the name lowercased plus a short random part, e.g. dashboard-k3x9q), so you never invent one, any name works and renaming never changes the id. The new app is PRIVATE: only you can open it, it is in no catalog and at no public URL until you call publish_app. Use this as the FIRST step whenever a user asks you to build them an app, a dashboard, a report page or a tool that runs on autario data | the public catalog (World Bank, FRED, Eurostat, OECD, WHO, IMF, ECB, US Census, SEC) or the user's own connector tables (Google Search Console, GA4, Google Ads, Meta Ads, YouTube, TikTok, Instagram, Facebook, Shopify, LinkedIn). Inside the HTML read data with autario.js, never with fetch (the sandbox has no network): autario.ready(), autario.datasets(), autario.query(datasetId, {limit, orderBy, where}), autario.artifacts.get/set(key), autario.rows.insert/select/update/delete(key, ...) on datasets the app declares in datasets_owned (contacts of a CRM, notes of each viewer); ready() gives user.role and an anonymous user.id per app, never the email of the viewer; autario inlines the SDK into every app, docs at https://autario.com/developer/docs/autario-js. Pass datasets with the ids of the user's own tables the app may read. Follow it with write_app_artifact (to save the app's data or saved views), get_app_preview_url (to hand the user a link to try) and publish_app (to make it public). Requires authentication.

Input Schema

NameRequiredDescriptionDefault
nameYesDisplay name of the app, free text up to 80 characters; the same name as another app is fine. The returned app_id is the name lowercased plus a short random part and never changes on a rename.
filesNoA multi-file app: index.html plus every file it loads by relative path (e.g. "app.js", "css/style.css", "img/logo.png", "about.html"). Paths are relative, use "/", no "..". Allowed: html, js, mjs, css, json, svg, png, jpg, webp, woff2. Max 50 files, 1 MB each, 2 MB in total. Put index.html in this list or pass it as content. Links between the HTML pages work, every page gets autario.js.
shelfNoThe app store shelf the app sits on, one id: search, analytics, social, ads, commerce, financial_markets, banking_accounting, crm, productivity, developer, ai, public_data. Pick the one that matches what the app is about (a dashboard of Instagram posts is social, an order report is commerce). Optional while the app is private; publish_app refuses with shelf_required until it has one. Any other value is refused with bad_shelf and the allowed ids.
contentNoThe app's entry document when entry_kind is "upload": one HTML file, or index.html when you also send files. It runs in a sandbox with no outbound network: read autario data through autario.js, not through fetch to third parties.
taglineNoOne line saying what the app does, max 200 chars. Worth writing: it is what a user reads in the app store, and an app cannot be indexed without one.
datasetsNoIds of the user's OWN datasets (connector tables, uploads; get them from get_my_workspace) this app may read through autario.js. Everyone the owner shares the app with (role reader and up) reads exactly these, nothing else. Public catalog datasets need no declaration.
entry_urlNoREQUIRED when entry_kind is "url". Must start with https://.
entry_kindNo"url" = the app already runs somewhere (give entry_url). "upload" = you are sending the app itself (give content or files). Default "url".
source_urlNoOptional link to the app's open source repository.
content_typeNoType of the uploaded content. Default text/html.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"Display name of the app. The app id is derived from it (lowercased, hyphenated); needs at least three letters or digits."New value: +"Display name of the app, free text up to 80 characters; the same name as another app is fine. The returned app_id is the name lowercased plus a short random part and never changes on a rename."
  2. Changed1 schema field changed
    • addedInput schema / properties / shelf
      Added value: +{
+  "description": "The app store shelf the app sits on, one id: search, analytics, social, ads, commerce, financial_markets, banking_accounting, crm, productivity, developer, ai, public_data. Pick the one that matches what the app is about (a dashboard of Instagram posts is social, an order report is commerce). Optional while the app is private; publish_app refuses with shelf_required until it has one. Any other value is refused with bad_shelf and the allowed ids.",
+  "type": "string"
+}
  3. Changed3 schema fields changed
    • changedInput schema / properties / content / description
      Previous value: -"REQUIRED when entry_kind is \"upload\". The app's entry document, normally a single self-contained HTML file. It runs in a sandbox with no outbound network: read autario data through the sandbox bridge, not through fetch to third parties."New value: +"The app's entry document when entry_kind is \"upload\": one HTML file, or index.html when you also send files. It runs in a sandbox with no outbound network: read autario data through autario.js, not through fetch to third parties."
    • changedInput schema / properties / entry_kind / description
      Previous value: -"\"url\" = the app already runs somewhere (give entry_url). \"upload\" = you are sending the app itself (give content). Default \"url\"."New value: +"\"url\" = the app already runs somewhere (give entry_url). \"upload\" = you are sending the app itself (give content or files). Default \"url\"."
    • addedInput schema / properties / files
      Added value: +{
+  "description": "A multi-file app: index.html plus every file it loads by relative path (e.g. \"app.js\", \"css/style.css\", \"img/logo.png\", \"about.html\"). Paths are relative, use \"/\", no \"..\". Allowed: html, js, mjs, css, json, svg, png, jpg, webp, woff2. Max 50 files, 1 MB each, 2 MB in total. Put index.html in this list or pass it as content. Links between the HTML pages work, every page gets autario.js.",
+  "items": {
+    "properties": {
+      "content": {
+        "description": "The file: text as is, binary (images, fonts) as base64 with encoding \"base64\".",
+        "type": "string"
+      },
+      "encoding": {
+        "description": "Default utf8.",
+        "enum": [
+          "utf8",
+          "base64"
+        ],
+        "type": "string"
+      },
+      "path": {
+        "description": "Relative path inside the app, e.g. \"js/app.js\".",
+        "type": "string"
+      }
+    },
+    "required": [
+      "path",
+      "content"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / datasets
      Added value: +{
+  "description": "Ids of the user's OWN datasets (connector tables, uploads; get them from get_my_workspace) this app may read through autario.js. Everyone the owner shares the app with (role reader and up) reads exactly these, nothing else. Public catalog datasets need no declaration.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  5. Added

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations (which already declare non-readonly, non-destructive, closed-world), the description discloses high-value behavior: the app is PRIVATE and at no public URL until publish_app, the sandbox has no outbound network so fetch is forbidden, autario.js is inlined into every app, the viewer's email is never exposed, and authentication is required. These are exactly the traits an agent cannot infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead is front-loaded and correct, but the body is a dense run-on paragraph stitched together with pipe separators and mid-sentence tool references, which makes it hard to scan. Nearly every clause carries information, so the problem is structure and length rather than filler.

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 10-parameter creation tool with no output schema, the description covers everything an agent needs: entry modes, file/size constraints, the SDK surface for reading data, dataset declaration, privacy state, authentication, and the follow-up workflow. Nothing material is left to guesswork.

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 100%, so the baseline is 3; the description earns above that by adding operational meaning the schema only partially restates — the id derivation ('name lowercased plus a short random part'), the hard size limits (512 KB content, 50 files / 1 MB each / 2 MB total), and the access-control semantics of `datasets` ('everyone the owner shares with reads exactly these, nothing else').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states a specific verb and resource ('Create a data app on autario in ONE call, owned by you') and immediately enumerates the two entry modes (https URL vs. hosted content/files). It also names the downstream tools it feeds into (write_app_artifact, get_app_preview_url, publish_app). The one gap is the sibling upload_app_bundle, which sounds closely related but is never differentiated from this tool.

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?

Explicit trigger conditions are given: 'Use this as the FIRST step whenever a user asks you to build them an app, a dashboard, a report page or a tool that runs on autario data', followed by the ordered sequence of follow-up calls. What's missing is an exclusion clause — nothing says when to prefer upload_app_bundle or another creation path instead.

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

All Autario 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