Autario

update_app_manifest

Idempotent

Update the manifest of an app YOU own: its name, tagline, entry URL, version, source repository and the autario datasets or operations it is allowed to read (consumed_datasets, which is what the sandbox bridge enforces at runtime: a World Bank or FRED dataset id, a live Yahoo quote op, or the caller's own Google Search Console and GA4 connector tables). Only the fields you pass change; everything else on the manifest is kept. Use it to declare data access after create_app, to put the app on its app store shelf (shelf), to declare that reports of the app may be shared on a secret link (share), or to rename or re-point an existing app. An app you do not own answers "not found". This never changes who may open the app: publishing is publish_app, deliberately a separate act.

Input Schema

Name	Required	Description
`name`	No	New display name. Omit to keep the current one.
`tier`	No	Runtime model. 2 = sandboxed custom app (the default for anything you build here). Only set this if you know you need 1.
`share`	No	Let a report of this app be opened on a secret read-only link, e.g. {"subjects":["account"],"sections":["meta","report"]}. "subjects" says WHOSE data a link points at and may only name kinds autario can resolve ("account" = the owner of the link, which is what a third-party app wants); "sections" is the list a link may request, and anything outside it is refused. Omit the key to leave the current setting alone. An app that has never declared this cannot be shared at all. The owner still decides per link who may open it: anyone with the URL, only signed-in people from named company domains, or only named addresses.
`shelf`	No	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.
`app_id`	Yes	The app id returned by create_app.
`tagline`	No	One-line description, max 200 chars.
`version`	No	Free-text version, e.g. "1.2.0". Bundles are stored per version.
`entry_url`	No	Where the app runs. An uploaded bundle uses the conventional "index.html".
`source_url`	No	Link to the open source repository.
`datasets_owned`	No	Datasets the app OWNS and writes through autario.rows (insert, select, update, delete), e.g. [{"key":"contacts","title":"Contacts","scope":"app","columns":[{"name":"email","type":"text","required":true},{"name":"deals","type":"integer"}]}]. scope "app" = one table of the app kept by the owner (readers read, editors write); scope "viewer" = one table per person looking at the app, readable only by that person (not by the owner). Types: text, number, integer, boolean, date (YYYY-MM-DD), timestamp (ISO with a time zone). Every written row is checked against these columns. A declared column cannot change its type and a key cannot change its scope; add new ones instead. Max 20 datasets x 50 columns. Omit to keep the current declaration.
`consumed_datasets`	No	What the app reads, e.g. [{"op":"datasetData","dataset":"<id>"}]. The sandbox bridge refuses any read the manifest did not declare. To read the connected accounts of whoever opens the app, add the connector keys: [{"op":"connectors","providers":["google_search_console","ga4"]}] \| those providers then appear on the Settings tab of the app with the connection state of that viewer, so a user who has not connected one can connect it from inside the app. Add "optional": true and "unlocks":"<what it adds>" for a source the app works without.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / datasets_owned

Added value: +{
+  "description": "Datasets the app OWNS and writes through autario.rows (insert, select, update, delete), e.g. [{\"key\":\"contacts\",\"title\":\"Contacts\",\"scope\":\"app\",\"columns\":[{\"name\":\"email\",\"type\":\"text\",\"required\":true},{\"name\":\"deals\",\"type\":\"integer\"}]}]. scope \"app\" = one table of the app kept by the owner (readers read, editors write); scope \"viewer\" = one table per person looking at the app, readable only by that person (not by the owner). Types: text, number, integer, boolean, date (YYYY-MM-DD), timestamp (ISO with a time zone). Every written row is checked against these columns. A declared column cannot change its type and a key cannot change its scope; add new ones instead. Max 20 datasets x 50 columns. Omit to keep the current declaration.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedOct 19, 2026

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"
+}

Changed1 schema field changedSep 21, 2026

addedInput schema / properties / share

Added value: +{
+  "description": "Let a report of this app be opened on a secret read-only link, e.g. {\"subjects\":[\"account\"],\"sections\":[\"meta\",\"report\"]}. \"subjects\" says WHOSE data a link points at and may only name kinds autario can resolve (\"account\" = the owner of the link, which is what a third-party app wants); \"sections\" is the list a link may request, and anything outside it is refused. Omit the key to leave the current setting alone. An app that has never declared this cannot be shared at all. The owner still decides per link who may open it: anyone with the URL, only signed-in people from named company domains, or only named addresses.",
+  "type": "object"
+}

Changed1 schema field changedSep 12, 2026

changedInput schema / properties / consumed_datasets / description

Previous value: -"What the app reads, e.g. [{\"op\":\"datasetData\",\"dataset\":\"<id>\"}]. The sandbox bridge refuses any read the manifest did not declare."New value: +"What the app reads, e.g. [{\"op\":\"datasetData\",\"dataset\":\"<id>\"}]. The sandbox bridge refuses any read the manifest did not declare. To read the connected accounts of whoever opens the app, add the connector keys: [{\"op\":\"connectors\",\"providers\":[\"google_search_console\",\"ga4\"]}] | those providers then appear on the Settings tab of the app with the connection state of that viewer, so a user who has not connected one can connect it from inside the app. Add \"optional\": true and \"unlocks\":\"<what it adds>\" for a source the app works without."

AddedSep 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare mutation (readOnlyHint=false), idempotency and non-destructiveness; the description adds the partial-update contract ('only fields you pass change; everything else is kept') and the failure mode for unowned apps ('not found'), which annotations cannot convey. It stops short of describing the response payload or other validation failure surfaces.

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?

The purpose and ownership constraint are front-loaded in the first clause, and the usage scenarios each carry distinct information. It runs long as a single dense paragraph, and the parenthetical catalog of data sources (World Bank/FRED ids, Yahoo quote ops, GSC/GA4) is more enumeration than an agent needs before choosing the tool.

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

Completeness4/5

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

For an 11-parameter partial-update mutation with no output schema, the description covers scope, partial-merge semantics, ownership errors, and the publish separation. The remaining gap is the return value — nothing says what the call returns after a successful update — though annotations cover the safety profile.

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, but the description adds genuine interpretive value by framing consumed_datasets as the runtime-enforced read allowlist the sandbox bridge checks, and by naming the accepted reader kinds (dataset id, live quote op, connector tables). It does not add anything for tier, share or datasets_owned beyond what the schema already documents.

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 ('Update the manifest of an app YOU own') plus the exact field set it touches (name, tagline, entry URL, version, source repository, consumed_datasets). It draws an explicit boundary against siblings create_app and publish_app, so an agent can place it in the lifecycle without opening any 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?

Enumerates concrete when-to-use cases: declare data access after create_app, assign a shelf, declare shareability, or rename/re-point an existing app. It also states an explicit when-not: 'This never changes who may open the app: publishing is publish_app, deliberately a separate act.' That is both a usage cue and a sibling redirect.

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

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